pastebin bezpośrednio z terminala

Hej,

Napisałem serwer, który pozwala udostępniać wynik programów konsolowych dla osób trzecich przy użyciu podstawowych narzędzi jak "nc" albo "socat". Demo najlepiej pokaże o co chodzi

$ echo "hello world" | socat - TCP:kl.kurwinet.pl:1337
upload complete, link to file https://kl.kurwinet.pl/o/gin9b
$ curl https://kl.kurwinet.pl/o/gin9b
hello world

A można też zrobić alias i jest jeszcze krócej

$ echo 'alias kl="socat - TCP:kl.kurwinet.pl:1337"' >> ~/.bashrc
$ source .bashrc
$ echo "easy send"|kl
upload complete, link to file https://kl.kurwinet.pl/o/wa84m
$ curl  https://kl.kurwinet.pl/o/wa84m
easy send

Można w ten sposób wysłać wklejkę każdego programu piszącego na stdout lub stderr jak, cat, gcc, make. Przy self-hostingu można włączyć szyfrowanie SSL, dzięki czemu będzie można dzielić się poufnymi (np firmowymi) wklejkami. Sam program, jest tylko serwerem, klient potrzebuje tylko nc albo socat, które to z reguły są już zainstalowane w systemie, a jak nie, to jest też metoda czysto bashowa:)

$ echo 'pure bash test' | { exec 5<>/dev/tcp/kl.kurwinet.pl/1338; cat - >&5; cat <&5; }
upload complete, link to file https://kl.kurwinet.pl/o/k4zu2

Licencja to BSD2, źródła: https://github.com/mlyszczek/kurload

O co proszę? O recenzję, jak się używa. Czy prosto skompilować, zainstalować, skonfigurować i odpalić. Czy w ogóle przydatny projekt i Wam się podoba. Czy może wam jakichś funkcji brakuje? Jak ktoś się zna na C to może i review kodu zrobić:)

Nie użyję dopóki nie zmienisz domeny na bardziej...
No nie wiem jaką, ta to wymysł gówniarza, żenada.
Pomysł ok, zamiast wiadomości wolałbym czysty link - przyda się w skryptach w razie czego

Pomysł ok, zamiast wiadomości wolałbym czysty link - przyda się w skryptach w razie czego

Dzięki za sugestie, wywaliłem nadmiarowe 'upload complete...', masz racje, łatwiej teraz chociażby do xclip output przenieść.

Nie użyję dopóki nie zmienisz domeny na bardziej...
No nie wiem jaką, ta to wymysł gówniarza, żenada.

Co do domeny, no cóż, taka moja natura. Zawsze możesz hostować u siebie z pełną kulturką. Są paczki binarne na popularne dystrybucje oraz init skrypty. Jak masz problem postawić to pomogę, bo to oznacza, że spieprzyłem dokumentację:)

Ja bym wolał jakiś json w odpowiedzi tbh

@kq, nie bardzo widzę przydatności zwracania jsona w przypadku jak dostajesz już linię z linkiem. Można sobie to dorzucić prosto do jakiegoś swojego jsona za pomocą jq

echo '{"foo": "bar"}' | jq --arg link "$(echo 'test'|kl|tail -n1)" '. +{"link": $link}'

Zwracanie jsona wymagałoby od użytkownika posiadania dodatkowego narzędzia do parsowania, które niekoniecznie jest na komputerze. tail ma każdy, nc prawie każdy.

• Operacje na cconn (server.c) nie muszą być owinięte w mutex - można by pokusić się o wykorzystanie jakichś typów atomowych.
• Zdaje się, że wykorzystujesz blokujące sockety (server.c:265) oparte o wątki (server.c:372) - IMO ciekawszym podejściem byłoby podejście z jednym wątkiem oraz socketami asynchronicznymi.
• Dlaczego wrzutki umieszczasz w plikach o uprawnieniach 644? 600 byłoby nieco bezpieczniejsze IMO. (edit: namierzyłem commit tłumaczący co i jak, więc nevermind)

Ogólnie gratki za napisanie takiej aplikacji - choć muszę przyznać, że wolałbym profesjonalnie takiego kodu nie rozwijać (z obawy przez bugami) i znacznie przyjemniej analizowałoby się taki serwer napisany w Go albo Rust ;-)

Patryk27 napisał(a):

• Operacje na cconn (server.c) nie muszą być owinięte w mutex - można by pokusić się o wykorzystanie jakichś typów atomowych.

Prawda, ale wtedy trzeba użyc standardu c11 albo nieprzenośnych konstrukcji, a ja chciałem tego uniknąć. Jednakże w sumie warto dodać flagę kompilacji i przy kompilatorze c11 używać atomic. Dobry pomysł.

• Zdaje się, że wykorzystujesz blokujące sockety (server.c:265) oparte o wątki (server.c:372) - IMO ciekawszym podejściem byłoby podejście z jednym wątkiem oraz socketami asynchronicznymi.

Na początku pisałem to właśnie przy użyciu pthread bo wiele rdzeni używa, równoległość itd. Ale później też analizowałem to i zrozumiałem, że w sumie ten program siedzi głównie w read() i write() czekając na dane z sieci i dysk aby zapisać je, a to nie wymaga równoległego przetwarzania, więc tak, mam to zapisane aby przerobić to na single thread (automatycznie też zniknie problem 1)

• Dlaczego wrzutki umieszczasz w plikach o uprawnieniach 644? 600 byłoby nieco bezpieczniejsze IMO.

Prawda, ale nie w gestii programu jest decydować jakie uprawnienia mają mieć pliki a integratora. W init skrypcie jest umask, którym można limitować to, przed startem serwera robisz umask 077 i masz uprawnienia 600. To jest ważne bo demon możesz postawić na jakimś dzielonym serwerze gdzie nginx może chodzić na uprawnieniach nginx:nginx, a demon być odpalany bez roota więc tworzone pliki będą user:user 600. W takim przypadku nginx nie będzie miał możliwości odczytać tych plików (i serwować ich użytkownikom) i będziesz miał serwer write only:)

Ogólnie gratki za napisanie takiej aplikacji - choć muszę przyznać, że wolałbym profesjonalnie takiego kodu nie rozwijać (z obawy przez bugami) i znacznie przyjemniej analizowałoby się taki serwer napisany w Go albo Rust ;-)

Ja po prostu jestem starej daty i bardzo lubię C, no i siedzę w hardcorowym embedded gdzie nie ma kompilatorów Go czy Rust, a króluje C, więc nie mam duże motywacji by się uczyć tego.

Dzięki wielkie za review:)

Jeszcze odnośnie tego JSONa: możesz wystawić serwer na dwóch portach - przy pierwszym porcie protokołem będzie JSON, a przy drugim czysty tekst ;-)

Po wczorajszej nagonce z udziałem wielu osób postanowiłem zmienić nazwę projektu i domenę strony demo. Teraz jest pełna kulturka.

Po zmianie teraz jest tak:

$ echo "hello world" | socat - TCP:termsend.pl:1337
upload complete, link to file https://termsend.pl/o/gin9b
$ curl https://termsend.pl/o/gin9b
hello world

A można też zrobić alias i jest jeszcze krócej

$ echo 'alias ts="socat - TCP:termsend.pl:1337"' >> ~/.bashrc
$ source .bashrc
$ echo "easy send"|ts
upload complete, link to file https://termsend.pl/o/wa84m
$ curl  https://termsend.pl/o/wa84m
easy send

Tak więc uaktualnione linki:

github: https://github.com/mlyszczek/termsend
strona projektu: https://termsend.bofc.pl
funkcjonalne demo: https://termsend.pl

Sorka jak kogoś uraziłem, nie chciałem:)

odnośnie tego JSONa: możesz wystawić serwer na dwóch portach - przy pierwszym porcie protokołem będzie JSON, a przy drugim czysty tekst ;-)

Już i tak są 4 porty, to tak by było łącznie 8 ich;p No i dalej nie rozumiem, po co json? Co się nim zyska? Ostatnia linia to zawsze goły link, to jest najprostsze i można wszystko z tym zrobić.
W przyszłości jednak planuję możliwość dodania argumentów do uploadu, np jak długo ma być być plik na serwerze, to może i dodam format danych zwrotnych.