26 stycznia 2012
Zmiana emulatora terminala.
#Notetoself: update-alternatives --config x-terminal-emulator
24 czerwca 2011
Clementine i pliki *.wma.
#Notetoself: do ich odtworzenia potrzebna jest wtyczka gstreamer-ffmpeg.
13 marca 2011
Odkurzenie GWhere.
Archiwa ze swoimi danymi (mejle, logi, konfigi, obrazki, doce wszelakie, save'y, itp. itd.) zbieram już lat dwanaście; przez ten okres uzbierało się nieco płyt. Plan na przyszłość* jest taki, żeby nabyć w końcu odpowiednio duży dysk zewnętrzny i przerzucić na niego zawartość wszystkich płyt. Chwilowo jednak dysku z przerzuconymi danymi nie mam, a częstokroć potrzebuję szybko znaleźć coś, co jest zawarte w archiwach. Kilka lat temu natknęłam się na GWhere - jest to aplikacja, katalogująca zawartość wszelakich nośników pamięci i umożliwiająca wygodne przeszukiwanie zasobów - i używałam go z powodzeniem przez kilka lat. Niestety projekt przestał być rozwijany w 2007 roku; a kiedy swego czasu zmieniłam system na Archa 64-bit, okazało się, że GWhere się nie kompiluje - wywala błąd o treści
../../../src/tools/libgwtools.a: could not read symbols: Bad value
Jako że z zasobami czasowymi u mnie nie bardzo, problem wisiał w TODO i czekał. (W międzyczasie spróbowałam znaleźć zastępstwo dla GWhere, ale zakończyło się to niepowodzeniem - nie znalazłam narzędzia o identycznej prostocie i funkcjonalności). Kilka wieczorów temu, zirytowana faktem, że potrzebuję szybko znaleźć coś w archiwach, a nie mam jak, postanowiłam wrócić do problemu. Guglnąwszy, ustaliłam, że rozwiązaniem wyżej wspomnianego błędu jest ustawienie dwóch zmiennych środowiskowych:
export CFLAGS="-Wall -fPIC" export CXXFLAGS="-Wall -fPIC".
Kolejna proba kompilacji zakończyła się tym razem błędem
‘LC_ALL’ undeclared (first use in this function)
Tu już guglanie nie pomogło, pomogła intuicja (albo ślepy strzał, jak kto woli) - rozwiązaniem okazało się po prostu dodanie w main.c inlude'a #include Program działa, znowu mogę swobodnie przetrząsać moje archiwa.
*gdzie przez przyszłość rozumiemy "po obronie pracy magisterskiej"
07 marca 2011
Szybki przepis na serwer FTP.
Nie mam nigdzie wykupionego hostingu, a nie lubię udostępniać plików z moich kont shellowych (m.in. dlatego, że upload jest kiepski). Zazwyczaj korzystam z hostingu bezpłatnego (np. wrzuc.net), te jednak mają to do siebie, że cechują się rozmaitymi niepożądanymi ograniczeniami (wielkość pliku) lub ich brakiem (plik nie jest usuwany z serwera, czego nie chcę). Swego czasu miałam postawiony serwer FTP, było to jednak parę lat temu - zmieniałam później komputer stacjonarny na laptopa, zmieniałam system (nawet nie raz) i jakoś nie miałam czasu, żeby ten nieszczęsny FTP postawić, wisiał jako wpis na liście TODO i czekał. Do teraz. Znajomi zaczęli się upominać o wystawienie zdjęć, co było dobrym pretekstem do tego, żeby wreszcie wziąć się do roboty.
Okazało się, że gdzieś po drodze zagubiłam stary, pieczołowicie przygotowany konfig (prawdopodobnie został na dysku peceta, przewiezionego do mojego domu rodzinnego). Jako że nie wszystko z poprzedniej zabawy FTP pamiętałam, odświeżoną receptę wrzucam tu - mnie może przydać się jeszcze w przyszłości, a może przyda się i komuś jeszcze.
Dla jasności, środowisko: system operacyjny Archlinux, serwer FTP - proFTFd. (Należy oczywiście pamiętać, aby instalować najnowszą wersję proFTPd, jako że pod koniec zeszłego roku znaleziono w nim lukę bezpieczeństwa. Plus obowiązkowa uwaga kronikarska, w razie gdyby ktoś nie wiedział - FTP nie jest bezpiecznym protokołem).
Założenie było takie, żeby z FTP-a mogło skorzystać kilku konkretnych użytkowników (nie będących użytkownikami systemowymi, a wyłącznie wirtualnymi) i aby nie byli to użytkownicy anonimowi.
A zatem: weźmij czarno kure^hhh yyyy... oczywiście - najpierw instalacja. W moim przypadku była to instalacja z repo, czyli po prostu pacman -S proftpd. Po zainstalowaniu, decydujemy, jaki ma być tryb uruchomienia serwera: (x)inetd czy standalone. W skrócie: w przypadku małego obciążenia nie ma to większego znaczenia. Gdy przewidujemy duże obciążenie i troszczymy się o zasoby - (x)inetd; gdy zasoby nie są problemem - standalone. (X)inetd pozwala oszczędzać zasoby systemowe (poprzez wywoływanie daemona ftp dopiero w chwili, gdy nadejdzie żądanie); z drugiej strony - daje mniejsze możliwości konfiguracyjne. Standalone pozwala na znacznie lepszą kontrolę procesu. Ja wybrałam standalone, z racji, że lubię mieć szerokie możliwości konfiguracyjne, a obciążenie przy takim domowym FTP-ie jak mój, nie ma znaczenia. Jako że chciałam, aby serwer uruchamiał się wraz z każdym uruchomieniem systemu - dopisałam go do listy daemonów w /etc/rc.conf.
Teraz najważniejsze, czyli plik konfiguracyjny proFTPd. Załączam swój (nieco tylko zmieniony) - sądzę, że komentarze umieszczone nad każdą z opcji wystarczająco wyjaśniają ich znaczenie:
# This is a basic ProFTPD configuration file (rename it to # 'proftpd.conf' for actual use. It establishes a single server # nazwa serwera - czyli to, co zobaczy użytkownik, logując się ServerName "moj_serwer" # tu może być wpisane cokolwiek - chodzi o to, żeby serwer nie podawał swojej wersji ServerIdent on "witaj na moim serwerze" # wspomniany wyżej tryb uruchamiania serwera ServerType standalone # skrótowo: użycie do obsługi wszystkich połączeń domyślnego serwera DefaultServer on # włączenie informacji, wyświetlającej się po udanym zalogowaniu DeferWelcome on # wiadomość pojawiająca się na powitanie, zawarta w pliku welcome.msg DisplayLogin welcome.msg # port, na którym nasłuchuje serwer Port 21 # użycie IPv6 UseIPv6 off # ustawienie praw do modyfikacji plików Umask 022 # liczba procesów potomnych (do ochrony przed atakim DDoS) MaxInstances 20 # użytkownik, na jakim działa serwer User ftp # grupa, do której przynależy powyższy Group ftp # ilość prób zalogowania się (pod rząd) MaxLoginAttempts 3 # maksymalna liczba podłączonych użytkowników MaxClients 10 "Zbyt wielu podlaczonych uzytkownikow - zaczekaj" # maksymalna liczba połączeń z danego IP MaxClientsPerHost 20 "Zbyt wiele polaczen z jednego IP" # timeouty - po jakim czasie bezczynności/logowaniu się/braku transferu serwer rozłączy użytkownika TimeoutIdle 300 TimeoutStalled 300 TimeoutStalled 300 TimeoutLogin 60 TimeoutNoTransfer 300 # uniemożliwienie logowania się jako root (domyślne, nawet jeśli nie umieszczone explicite w konfigu) RootLogin off # katalog, do którego trafi użytkownik po zalogowaniu DefaultChdir ~ # "zamknięcie" użytkownika w danym katalogu; nie będzie w stanie wejść powyżej DefaultRoot ~ # użytkownik nie wylistuje ukrytych plików ListOptions "+a" # zezwolenie na nadpisywanie plików AllowOverwrite on # usuwanie plików z niedokończonych sesji DeleteAbortedStores on # zapobieganie niezauważaniu niedociągnięcia plików HiddenStores on # użytkownik nie może używać własnego pliku .ftpaccess <Directory /> AllowOverride off # użytkownik nie widzi katalogów, do których nie ma uprawnień HideNoAccess on # niewyświetlanie użytkownikowi plików ukrytych <Limit CWD PWD LIST> IgnoreHidden on # brak zezwolenia na zmianę uprawnień do pliku </Limit> <Limit SITE_CHMOD> DenyAll </Limit> </Directory> # lista użytkowników, uprawnionych do korzystania z ftpa AuthUserFile /etc/ftpd.passwd # pozwala dostosować logowanie ExtendedLog /var/log/proftp.log # zezwala na korzystanie z ftpa użytkownikom wirtualnym RequireValidShell off
Teraz pora na utworzenie katalogu, który będzie udostępniany oraz nadanie mu odpowiednich praw: mkdir /home/ftp chown ftp:ftp /home/ftp chmod 755 /home/ftp i wreszcie - utworzenie użytkowników, którzy będą korzystać z naszego FTP-a. Jak już wspominałam, są to użytkownicy wirtualni, nie systemowi. Tym samym w systemie postrzegani będą jako użytkownik, na którym działa serwer ftp. Użytkowników tych stworzyłam za pomocą narzędzia ftpasswd, o którym to narzędziu dowiedziałam się na ulos.pl. Binarkę wystarczy dorzucić do pozostałych ftpowych binarek (u mnie - katalog /usr/bin). ftpasswd --passwd --file /etc/ftpd.passwd --name nazwa_usera --home /home/ftp/nazwa_usera -p --uid id_usera_ftp --gid id_grupy_ftp --shell /bin/false
Parametr --file musi być taki sam jak wartość AuthUserFile w konfigu. UID i GID wymagane w powyższym poleceniu to wartości przypisane użytkownikowi i grupie z pola "User" oraz "Group" z pliku proftpd.conf. Parametr shell ustawiony na /bin/false powoduje, iż użytkownik nie będzie miał dostępu do powłoki systemowej.
Pozostało jeszcze uniemożliwienie korzystania z ftpa użytkownikom systemowym, co realizuje się bardzo prosto: wystarczy stworzyć plik /etc/ftpusers i wpisać tam nazwy wszystkich użytkowników, których zabraniamy dostępu do ftpa. Ja zabroniłam wszystkim, zatem najszybciej było mi to zrobić tak: awk -F":" '{print $1}' /etc/passwd > /etc/ftpusers i usunąć z listy użytkownika, na którym działa serwer (w przykładzie: ftp). Aby zmiany w konfiguracji odniosły skutek, należy zrestartować serwer: /etc/rc.d/proftpd restart Ot i tyle. Więcej przydatności w docsach, np. tu.
