пропозиції роботи
Wypowiedzi
-
aczkolwiek nie jest dobrze zapisywać hasła w skryptach ale w moim przypadku serwer był wewnętrzny i żadnych ważnych danych na nim nie było, wyłącznie jakieś nikomu nic nie mówiące cyferki :)
-
Marcin Kaczmarek:
A idzie zalogować się do serwera bez generacji rsa bo nie mam konto na unixie ale nie mam tam uprawnień do generacji rsa i zrobienia logowania po ssh bez hasła>
Parę lat temu wydłubałem skrypcik do łączenia się z serwerem FTP i pobieraniem jakiś folderów z określonymi datami ale mniejsza o to. Napisałem coś takiego:
ftp -v -p -in $ftpserver <<**
quote USER $username
quote PASS $password
lcd /home/jakislogin/$wczoraj
mget cos.tar.gz
dokładnie nie pamiętam ale chyba "<<**" oznaczało, że następne linijki będą przekierowywane do uruchamianego programu.
PozdrawiamMichał Dziewański edytował(a) ten post dnia 09.06.12 o godzinie 08:21 -
no dobra, z tymi dyskami to może na zbytnio przesadziłem ale ja cenie sobie środowisko bez zbędnego softu i bajerów, które zbędnie zawalają pamięć i machają głowicą dysków :)
-
Michał Kowal:
Ale kombinujecie. Ludzie.. zacznijcie używać normalnych tooli a nie 'sznurka i druta i jakoś to będzie'. Jakieś tary, cuda nie widy nadają się do prostych (lub innych) rzeczy natomiast pliki konfiguracyjne najlepiej trzymać w jakimś RCS. Dlaczego? Ano:
- możliwość dodawania komentarzy do commitów i np. po kilku tyg. widać na wykresach jakieś anomalie, szukamy danego commita i od razu widzimy w komentarzu, że np. zmieniane były jakieś sysctl i pewnie to ta zmiana powoduje problem
- wersjonowanie
- proste i szybkie wyświetlanie różnic
- proste i szybkie przechodzenie pomiędzy poszczególnymi zmianami nawet o odległe wersje
- znani autorzy zmian (wiadomo do kogo potem się przywalić jak coś zepsuł)
- wyszukiwanie zmian po całym repo
- proste przerzucanie konfiguracji na inne serwery
- porównywanie konfiguracji (lub części konfiguracji) między serwerami
- możemy dodać do crona np. porównywanie plików z jakąś 'żelazną wersją' w repo i jak ktoś nieopatrznie coś zmieni to cron nam wyśle maila o zmianie
Powyższych może być znacznie więcej w zależności co trzymamy, jak duże jest środowisko, ilu ludzi tam ma dostęp i jakiego narzędzia używamy. Powyższe 'plusy dodatnie' zależą oczywiście od konkretnego użytego RCS. Oczywiście nie znając np. git'a (ja tego używam) trzeba najpierw poświęcić trochę czasu na nauczenie się go. Jednak po jakimś czasie człowiek zastanawia się jak mogło tyle wody w Wiśle upłynąć bez wdrożenia takiego narzędzia. Pomysłu z wysyłaniem /etc do jakiejś chmury nie ma co komentować. Jeżeli już chcemy to najlepiej wysyłać do swojego centralnego repo gdzieś na swoim serwerze. No chyba, że chcemy publikować/trzymać 'gdzieś lecz nie wiadomo gdzie' te pliki to już inna sprawa.
No soft na pewno ciekawy ale trzeba pamiętać też o wydajności serwerka, naćka się takiego softu a później się ludzie dziwią że usługi wolno chodzą bo np. dyski się nie wyrabiają. -
Marcin Bojko:
Im mniej ręcznie wyrzeźbionych skryptów (najlepiej odpalanych w kaskadzie), uzależnionych osobowo od autora albo głównego czającego - tym lepiej.
No tak jak napisałem, wszystko zależy od roli serwerka. Zgadzam się z Tobą, wiem dobrze, o co Ci chodzi. Bardzo ważna jest odpowiednia dokumentacja do skryptów. Z tym, że uważam, że dobry administrator powinien też umieć czytać skrypty, a ten, o którym pisałem na początku nie jest skomplikowany i zająłbym z komentarzami ~7 linijek :) -
Michał Panasiewicz:
inna sprawa, że te wrażliwe pliki powinny być monitorowane, ich zmiana może wskazywać na to że system został skompromitowany.
Pozostałe:
Twój każdy skrypt to też dodatkowe oprogramowanie. (większość podobnych projektów to też pojedyncze skrypty, tylko że lepiej przetestowane, przez większą liczbę osób)
Każdy twój skrypt będzie się rozrastał, będziesz dokładał nową funkcjonalność, wynajdował koło od początku - lepiej tą pracę skierować na rozwój któregoś z już istniejących projektów.
Bałagan w plikach - jak używasz paczek i przestrzegasz "Distribution way" to masz porządek.
Podejście programisty: to napiszę sobie skrypcik/program
Podejście administratora: znajdę przetestowane, rozwijane rozwiązanie, które sprawdza się.
Niby tak ale mając własny skrypt, a jak coś się zwali to wiesz praktycznie od razu na czym utknęło i możesz wprowadzić poprawki. Skrypt który napiszesz będzie zawierał tylko to co potrzebujesz bez jakiś wymyślnych dodatkowych funkcji, które autor ściągniętego programu pomyślał, że jak już coś pisze to dopisze i to bo może akurat komuś się przyda. Instalując gotowca znając życie musisz doinstalować jakieś zależności a pliki mogą być porozrzucane po filesystemie. Ale jak wspomniałem wcześniej wszystko zależy od stopnia skomplikowania skryptu/oprogramowania. W tym wypadku pokusiłbym się o napisanie coś własnego :) -
Michał Panasiewicz:
a potem trzeba poprawiać bo jeden matoł z drugim na każdym serwerze swoje wydumki instaluje. Zamiast znaleźć używane i supportowane rozwiązanie.
Im mniej softu zainstalowanego tym lepiej i większa kontrola nad wydajnością/stabilnością systemu... Zresztą supportowane rozwiązania w przypadku biznesu tak aby nie czekać dniami na rozwiązania na forach to $$$. Fakt faktem wszystko zależy od "ważności" i roli naszego serwerka ale w tym przypadku nie jest to skomplikowane problem i uważam, że skrypt własnej roboty dałby sobie spokojnie radę.
a potem trzeba poprawiać bo jeden matoł z drugim na każdym serwerze swoje wydumki instaluje.
Są też "#". Skrypty też trzeba umieć czytać :)
A tak w ogóle to odbiegamy od tematu, kolega zakładający post potrzebuje proste rozwiązanie a serwer nie jest raczej strategiczny (ubuntu) i może nawet jest to rozwiązanie domowe a my rozważmy rozwiązanie na wyrost. -
są od tego gotowce? Etckeeper robi to samo co Twój skrypt i jeszcze grzecznie wkłada do repo w gicie.
pewnie i jest, ale większa przyjemność jest ja się samemu coś wydziabie i jeszcze będzie "lżejsze" bo będzie zawierać tylko tyle co się potrzebuje. Czasem samemu szybciej się coś wystruga niż spędzi czasu na goolowanie + konfigurację + testy :)Michał Dziewański edytował(a) ten post dnia 10.05.12 o godzinie 19:53 -
no to możesz przecież do pliku wypisać listę plików, które starowałeś z datą. Później tylko cat + grep.
Zresztą:
"Cała ta operacja nie ma działać jak kopia zapasowa, raczej jako lista kroków które wykonałem, by mieć "bazę" na przyszłość ;)"
Czyli nie piszę to co jest najlepszym wyjściem backup'owym tylko to co chce zrobić założyciel postu :) -
Damian Usnarski:
hmmm, a może lepiej wydłubać skrypcik, który:
Krzysztof P.:
Nie ma sensu tego wersjonować. Prościej jest za każdym razem zrobić z niego tar.gz i wrzucić
do jakiejś "chmurki". W Inecie jest mnóstwo serwisów, które za darmo przechowują pliki do paru GB.
Do tej pory właśnie tak robiłem, cała zawartość skompresowana to ledwie 200KB, tak więc rozmiar żaden. Jednak lubię mieć, że tak powiem, changelog pod ręką :) Jestem wyuczonym programistą, sysadminki się dopiero uczę bo raz, że chcę rozszerzyć specjalizację, a dwa, zostałem do tego nijako zmuszony, a do wersjonowania mam po prostu sentyment. W momencie, gdy coś sieknie mi na serwerze przez mój błąd, chciałbym móc przeanalizować zmiany wstecz, a, że nie lubię robić ręcznie changelogów, dlatego postanowiłem wrzucić wszystko przez Git'a.
Cała ta operacja nie ma działać jak kopia zapasowa, raczej jako lista kroków które wykonałem, by mieć "bazę" na przyszłość ;)
1* find'em znajdzie pliki zmienione dzien wstecz
2* ztaruje wyszukane pliki
3* wysle ztarowany plik powiedzmy na mail
4* a jak bedzie brak plików to na wszelki wypadek niech stworzy pusty plik "brak_nowych_plikow.txt", ztaruje go i wyśle na wspomnianego maila.
Na koniec dopisać linijkę do crontab na wykonywanie codzienne rano.
?
- 1
- 2
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
Zaloguj się za pomocą
