Temat: Delikatne dane w katalogu /etc

Michał Dziewański:

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 :)

True.

Temat: Delikatne dane w katalogu /etc

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.Michał Kowal edytował(a) ten post dnia 12.05.12 o godzinie 10:06

Temat: Delikatne dane w katalogu /etc

Widzisz, chmura jest naturalnym rozwinięciem idei gita - bez tego szmatławego etapu z zapewnianiem swojej infrastruktury i jej niezawodności.
Wystarczy chwila pomyślunku jak w przypadku Dropboxa czy SugarSynca i masz rozwiązanie spersonalizowane i poszerzone o jeden etap do przodu.

Temat: Delikatne dane w katalogu /etc

Marcin Bojko:
Widzisz, chmura jest naturalnym rozwinięciem idei gita - bez tego szmatławego etapu z zapewnianiem swojej infrastruktury i jej niezawodności.
Wystarczy chwila pomyślunku jak w przypadku Dropboxa czy SugarSynca i masz rozwiązanie spersonalizowane i poszerzone o jeden etap do przodu.

Jestem wyjątkowo oporny na różnego rodzaju nowinki :) Np. fej-zbuka aka facebook nie mam do tej pory a przyznanie przed samym sobą, że nie wszystko należy pisać w C zajęło mi sporo czasu :) Smartphone też nie mam, pewnie wcisną mi za darmo jak już będzie jakiś android-ng-new-extra-2015-super-hiper-all-mighty :)

Temat: Delikatne dane w katalogu /etc

Michał Kowal:

Marcin Bojko:
Widzisz, chmura jest naturalnym rozwinięciem idei gita - bez tego szmatławego etapu z zapewnianiem swojej infrastruktury i jej niezawodności.
Wystarczy chwila pomyślunku jak w przypadku Dropboxa czy SugarSynca i masz rozwiązanie spersonalizowane i poszerzone o jeden etap do przodu.

Jestem wyjątkowo oporny na różnego rodzaju nowinki :) Np. fej-zbuka aka facebook nie mam do tej pory a przyznanie przed samym sobą, że nie wszystko należy pisać w C zajęło mi sporo czasu :) Smartphone też nie mam, pewnie wcisną mi za darmo jak już będzie jakiś android-ng-new-extra-2015-super-hiper-all-mighty :)

Więc odpowiem Ci Michale: ... ale kombinujesz... zacznij używać normalnych tooli i wtedy zadasz sobie pytanie: jak można było bez nich żyć ;)
PS. Nie dotyczy fejs-zbooka :P

Temat: Delikatne dane w katalogu /etc

Marcin Bojko:

Michał Kowal:

Marcin Bojko:
Widzisz, chmura jest naturalnym rozwinięciem idei gita - bez tego szmatławego etapu z zapewnianiem swojej infrastruktury i jej niezawodności.
Wystarczy chwila pomyślunku jak w przypadku Dropboxa czy SugarSynca i masz rozwiązanie spersonalizowane i poszerzone o jeden etap do przodu.

Jestem wyjątkowo oporny na różnego rodzaju nowinki :) Np. fej-zbuka aka facebook nie mam do tej pory a przyznanie przed samym sobą, że nie wszystko należy pisać w C zajęło mi sporo czasu :) Smartphone też nie mam, pewnie wcisną mi za darmo jak już będzie jakiś android-ng-new-extra-2015-super-hiper-all-mighty :)

Więc odpowiem Ci Michale: ... ale kombinujesz... zacznij używać normalnych tooli i wtedy zadasz sobie pytanie: jak można było bez nich żyć ;)
PS. Nie dotyczy fejs-zbooka :P

Z wielu stron słyszę takie porady, chyba problem jest we mnie :)
Wracając do tematu: jeżeli nawet serwer jest mały albo służy do nauki to i tak polecam użycie jakiegoś RCS, można się czegoś ciekawego nauczyć, a niewątpliwie RCSy są takimi ciekawymi rzeczami (i szeroko stosowanymi), np. w ogłoszeniach o pracy dla programistów praktycznie wszędzie jest jako wymagana umiejętność korzystania z cvs, svn, gita czy jeszcze czegoś innego.

Temat: Delikatne dane w katalogu /etc

Michał Kowal:
np. w ogłoszeniach o pracy dla programistów praktycznie wszędzie jest jako wymagana umiejętność korzystania z cvs, svn, gita czy jeszcze czegoś innego.

Tak przy okazji i w temacie (trzymania plików etc) - w ogłoszeniach dla adminów bardzo popularny jest puppet ;)

Temat: Delikatne dane w katalogu /etc

Dlaczego zawsze odnoszę wrażenie że sporo osób w skrajności wchodzi???

Używanie gotowych i sprawdzonych tool-i nie oznacza nieznajomości/nieumiejętności czytania skryptów, korzystania z RCS itd.
Wręcz przeciwnie, korzystasz z gotowych tooli i INTEGRUJESZ JE np: z RCS, AD, itd.
"Sznurek i drut" to zawsze najgorsze rozwiązanie i ostateczność. Sam widziałem/znam świetnych fachowców którzy przez takie podejście "zakopali się" w supportowaniu/rozwijaniu własnych "wydumek". Co powoduje że z jednej strony znają świetnie system, potrafią programować, a z drugiej przez takie podejście są w bardzo ograniczonym stopniu przydatni przy średnich/dużych biznesowych projektach, oraz nie rozwijają się, nie znają nowoczesnych rozwiązań używanych w biznesie.

Temat: Delikatne dane w katalogu /etc

Wojtek Bojdoł:

Michał Kowal:
np. w ogłoszeniach o pracy dla programistów praktycznie wszędzie jest jako wymagana umiejętność korzystania z cvs, svn, gita czy jeszcze czegoś innego.

Tak przy okazji i w temacie (trzymania plików etc) - w ogłoszeniach dla adminów bardzo popularny jest puppet ;)

Chef, puppet - to rozwiązania nie tyle do trzymania samej konfiguracji co do całościowego zarządzania dużym środowiskiem, zarządzania zmianą itd.

Temat: Delikatne dane w katalogu /etc

@Damian Usnarski
Może i przyrostowy, ale możesz kasować po x dniach.
Bo jeśli masz zamiar robić kopię plików zmienionych + opis to bardzo ciężko to zrobić. Bo musisz edytować plik, a potem opisać co zmieniłeś. Tego automat już nie zrobi :(

Ja np robię tak, że mam system + chroot (tutaj właściwe usługi). Chroot jest kopiowany na zewnętrzny serwer i pakowany + zabezpieczenia. Za nim wykona mi się kopia, wcześniej usuwa mi skrypt kopie starsze niż x dni. Bo nie widzę potrzeby trzymania kopi np. powyżej 100 dni.

Temat: Delikatne dane w katalogu /etc

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ą.

Temat: Delikatne dane w katalogu /etc

Michał Dziewański:

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ą.

o_O

Temat: Delikatne dane w katalogu /etc

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 :)

Temat: Delikatne dane w katalogu /etc

ech ... po to właśnie dobiera się odpowiedni tool do zadania, odpowiednio go konfiguruje i optymalizuje.
Optyka zmienia się jak masz >200 maszyn pod sobą.

Temat: Delikatne dane w katalogu /etc

Również polecam changetrack.

Natomiast jeśli chcesz dla własnej przyjemności się pobawić, to możesz jeszcze zrobić backup całego serwera lub tylko wybranych katalogów na zdalny serwer z użyciem rsnapshota raz na godzinę lub raz na dzień + napisanie skryptu który zrobi diffa na dwóch ostatnich katalogach i wyśle go mailem.
Ewentualnie regularny LVM snapshot + (tak samo jak powyżej) napisanie skryptu który zrobi diffa na dwóch ostatnich snapshotach i wyśle go mailem.

Temat: Delikatne dane w katalogu /etc

Maciej Korzeń:
Również polecam changetrack.

Natomiast jeśli chcesz dla własnej przyjemności się pobawić, to możesz jeszcze zrobić backup całego serwera lub tylko wybranych katalogów na zdalny serwer

Zdalny serwer .. do którego dostęp ma .... <tu wyliczyć kto>.

Jeśli w <...> jest bliżej nieznana grupa osób, to nie ma sensu robić backupu na ten serwer. W przeciwnym przypadku można tam składować wyłącznie zaszyfrowane "własnoręcznie" pliki.

Temat: Delikatne dane w katalogu /etc

Krzysztof P.:
Zdalny serwer .. do którego dostęp ma .... <tu wyliczyć

> kto>.

Jeśli w <...> jest bliżej nieznana grupa osób, to nie ma sensu robić backupu na ten serwer. W przeciwnym przypadku można tam składować wyłącznie zaszyfrowane "własnoręcznie" pliki.

No wiadomo, że backupowałbym na mój, a nie Twój serwer. :-D

Chodzi o to, żeby backupy trzymać na innej fizycznej maszynie niż źródłowa. Aczkolwiek tematem wątku jest śledzenie zmian w /etc, a nie same backupy, więc jeśli rsnapshot wykorzystamy tylko do śledzenia zmian, to nie ważne gdzie będziemy trzymać kopię.Maciej Korzeń edytował(a) ten post dnia 17.05.12 o godzinie 22:10

Temat: Delikatne dane w katalogu /etc

Maciej Korzeń:
Również polecam changetrack.

...

Ewentualnie regularny LVM snapshot + (tak samo jak powyżej) napisanie skryptu który zrobi diffa na dwóch ostatnich snapshotach i wyśle go mailem.

trzymanie snapshotów obniża wydajność pamięci masowej dla maszyny

Temat: Delikatne dane w katalogu /etc

Z moich doświadczeń najlepiej sprawdza się etckeeper (podglad lokalnych zmian "na szybko" + przy odpowiednich hookach można mieć info "co dokładnie zmienił dany commit puppeta") oraz puppet + jakiś RCS typu Git + admini podający w commitach nr. ticketu czego to dotyczy (to warto wymusić commit hookiem żeby ktoś nie zapomniał + ew. jakiś tag do szybkich fixów bez nr. commita)

Rezultatem jest to że można zobaczyć przez git blame kto dodał tą linijkę configa która coś psuła, kiedy to dodał i dlaczego.

"Puppecenie" zaczyna się zwracać już przy 3-4 maszynach, dodatkową zaletą jest to że zrobione kompleksowo pozwala zreinstalować serwer/dodać nowy bardzo szybko, praktycznie to instalka (którą też można ofc zautomatyzować) + odpalenie puppeta i pójście na kawę. Zrobione jak trzeba automatycznie doda serwer do nagiosa, doda wykresy do monitoringu, ustawi backup itd. bez zbędnego klikania po maszynach.

A tylko do "backupu configów" to etckeeper + cron robiący commit co jakiś czas (na wszelki jak admin zapomni) + git push do zdalnego serwera. Można jeszcze dodać żeby w commitlogu zapisywał np. kto był w tym czasie zalogowany ;]