simple brainteaser. take no more than 30 seconds to think about it:

using standard cron installed on your unix system, how often would this command be run:

*/57 * * * * command

? if you choose to answer in comments, please supply version of cron that your system is using.

there is this situation: multiple people have to have access to single system account on unix/linux.

you are one of them, but you really want to have your own environment. aliases, path, and so on.

problem? others dont want your changes. is it a lost case?

- MORE -

[ wersja polska poniżej ]

english version

just found this nice brain teaser.

i have this code in bash:

echo -e "1 1\n2 2" | while read A B; do echo "[$A] [$B]“; echo “ZZZ”; done

it will print:

[1] [1]
ZZZ
[2] [2]
ZZZ

which is perfectly valid and sensible.

but if i’ll change the command to:

echo -e "1 1\n2 2" | while read A B; do echo "[$A] [$B]“; ssh localhost date; echo “ZZZ”; done

i.e. i added ’ssh localhost date’ which connect to localhost over ssh, logins to my own account, and issues “date” command (can be any command), it shows only:

[1] [1]
Tue Sep 18 15:45:24 CEST 2007
ZZZ

and finishes work. (i have a password-less login in localhost, so it doesn’t ask for password).

and the question is: why there is no second step of while loop?

( side note: i know the answer, it’s just a riddle for you

wersja polska

trafiłem właśnie na niezłą łamigłówkę:

poniższa linijka w bashu:

echo -e "1 1\n2 2" | while read A B; do echo "[$A] [$B]“; echo “ZZZ”; done

wypisze:

[1] [1]
ZZZ
[2] [2]
ZZZ

co jest w pełni sensowe i oczekiwane.

ale jeśli zmienię ją na:

echo -e "1 1\n2 2" | while read A B; do echo "[$A] [$B]“; ssh localhost date; echo “ZZZ”; done

tzn. dodam ’ssh localhost date’, co łączy się na moje konto na localhoście i wykonuje polecenie “date” (może to być dowolne polecenie), wynikiem całości jest tylko:

[1] [1]
Tue Sep 18 15:45:24 CEST 2007
ZZZ

i to koniec (mam logowanie bezhasłowe więc nie ma prośby o hasło).

pytanie: czemu nie ma drugiego wykonania kodu w pętli while?

( oczywiście (jak przy poprzednich łamigłówkach) znam odpowiedź ).

i have been given a machine with 2 discs (2x 160gb, sata), linux debian 4.0 and a task to make it run as raid1.

in the begining layout was simple:

disc: /dev/sda had 2 partitions:

• sda1 - 2gb, swap
• sda2 - rest of disc, root filesystem

second disc (sdb) didn’t have any partitions.

it was up to me what exactly i will do, but the outcome had to be:

• all important data will be in raid1 setup on both discs
• current data cannot be lost
• installing everything from scratch is not an option.
• machine has lilo loader on it, and it shouldn’t be changed

so, after some tests i did it, and will write about how to do it for future reference.

all naming conventions in following text will use names on the machine described above (sda1, sda2, sdb).

1. of course: apt-get install mdadm. mdadm is the tool to make raid arrays on linux.
2. since debian kernel has everything important loaded - i dont need to, but you can: modprobe md_mod; modprobe raid1
3. create 2 partitions (sdb1, sdb2) on sdb disc. their layout and sizes should be the same as on source disc. in my case i decided to use sdb1 partition as /tmp disc - 2gb should be enough
4. let’s create filesystem on sdb1 partition (future /tmp space) : mkfs -t ext3 /dev/sdb1
5. now. i need to create md0 device (it didn’t exist in my system. if it does in your - just skip this point). to create you use: mknod -m 0660 /dev/md0 b 9 0; chgrp disk /dev/md0
6. once i have /dev/md0, i create the array. i do so, by creating new array in raid1 mode, that will contain sdb1 partition and “missing” disc. this means that this partition will be in “degraded” mode, but this is perfectly fine for us
7. mdadm –create /dev/md0 -l1 -n2 /dev/sdb2 missing
8. now, the filesystem on /dev/md0: mkfs -t ext3 /dev/md0
9. then you should edit /etc/fstab, and modify it to change device for rootfilesystem from “/dev/sda1″ to “/dev/md0″. ready line can looks like this: “/dev/md0 / ext3 defaults 0 1″
10. i add information about /tmp to fstab: “/dev/sdb1 /tmp ext3 defaults,errors=continue,noexec,nosuid 0 0″. it is very important to use “0″ at the end - otherwise, if one of disc would fail, system will not bootup correctly claiming that it can’t mount /tmp.
11. in /etc/lilo.conf i modify “root=” entry to point it to /dev/md0: “root=/dev/md0″. “boot=” stays “/dev/sda”
12. mkdir /mnt; mount /dev/md0 /mnt; cd /; tar cf - –exclude=./proc –exclude=./mnt –exclude=./sys . | ( cd /mnt; tar xvf - )
13. above series of commands will make /mnt directory, mount our raid device there, and copy whole filesystem to it.
14. since i skipped /proc and /sys, i have to create them now, and fix permissions: mkdir /mnt/proc /mnt/sys; chmod 555 /mnt/proc
15. ok. now we have: root filesystem on /dev/sda2, 2-device raid1 on /dev/sdb2 (and a missing disc), with copy of root filesystem. configured /etc/fstab and /etc/lilo.conf. so, just issue “lilo” command to install new bootblock (should go without errors), and reboot machine.
16. after bootup root filesystem should be mounted on /dev/md/0, and cat /proc/mdstat should show that this array (md0) is working, but degraded.
17. now, we add unused (at the moment) /dev/sda2 to md0: mdadm –add /dev/md0 /dev/sda2
18. raid rebuild process now works. it’s progress can be seen by viewing /proc/mdstat file. full rebuild took me about 40 minutes. we can’t proceed before rebuild finishes.
19. after it finished, we have to modify /etc/lilo.conf once again. this time, “boot=” parameter should be changed to “/dev/md0″, and we should add new parameter: “raid-extra-boot=/dev/sda,/dev/sdb”
20. after modifications of lilo.conf we should issue “lilo” command to make the change permanent.
21. at the moment the mogration practically finished. we can simply do one more reboot to test if it will work (should, and it did work for me

now, the procedure i shown above is not meant to be a full fledged raid howto or manual. there are better sources for this kind of information.

this procedure is only meant to help in similar cases (lilo, migration of root filesystem to raid1).

if you have any questions about it - do not hesitate to ask. and if you dont understand something - please tell me so - i’ll be glad to fix all that’s not clear.

firmą która nieoczekiwanie (dla niej samej też) zaczęła nieźle zarabiać na linuksie okazało się hp.

w sierpniu 2005 roku ogłosili, że debian sarge będzie w pełni supportowany na ich serwerach. efekt? w roku rozliczeniowym 2006 okazało się, że mają sprzedaż za $25 milionów - sprzedaż która jest bezpośrednio powiązana z faktem istnienia tego supportu.

szefostwo hp’ka jest dosyć mocno zadowolone (też bym był) i zamierzają to dalej rozwijać. w toku jest ewaluacja etch’a (do tej pory supportem objęty jest jedynie sarge).

co ciekawe - debian nie jest pierwsza supportowana dystrybucja - wcześniej były suse i redhat, ale debian jest pierwszą całkowicie darmową. supportem objęte były jedynie komercyjne wersje suse i redhata.

tak czy inaczej - mnie to cieszy. używamy sporo hp’ków i fakt, że poważnie podchodzą do używania debiana bardzo mnie cieszy. a że na tym zarabiają - super, w końcu nie są organizacją charytatywną.

czasem przydałaby się możliwość wyczyszczenia cache’a dyskowego. jeśli potrzebujemy tego w kontekście jakiejś pobocznej partycji to wystarczy odmontować i zamontować.

ale co jeśli nie możemy tego zrobić? root file system. albo chociażby fs którego potrzebujemy.

neil conway wpadł na rozwiązanie, a ja je powtarzam za nim:

wystarczy:

echo 1 > /proc/sys/vm/drop_caches

przy czym ten plik istnieje dopiero od linuksa 2.6.16.

wykonanie polecania powoduje wyczyszczenie tych buforów które można (nie wszystkie można). efekt. na maszynie z uptime’em 12 minut, klasy desktop, zajętość buforów spadła z 512 na 140 megabajtów!.

po co to komu? najprościej - do benchmarków. słodkie.

dowiedziałem się przypadkiem o firmie "system76". jest ona podobno jednym z największych "supporter’ów" (nie mam pojęcia jak to przetłumaczyć by zachować sens) ubuntu. a co robi? sprzęt. pecety. i laptopy. bez windowsów, za to z linuksem.
jeśli kiedyś stawialiście linuksa na lapie wiecie, że nie jest słodko. hibernate, suspend, grafika, dźwięk, apm/acpi. wszystko to generuje problemy.
ale nie na sprzęcie system76!.
oni budują i konfigurują wszystko od podstaw tak by śmigało i nie generowało problemów.
a do tego - specyfikacje są naprawdę niezłe (nie będę cytował bo to i tak trzeba zobaczyć, a przecież nie zrobię kopii całego site’u).
co ciekawe - we wzornictwie widać ewidentne wpływy apple’a. w szczególności w modelu koala (desktop, wyglądający mniej więcej jak macmini).
dodatkowo - dowiedziałem się, że za mniej więcej 2 tygodnie ma wejść do sprzedaży nowy model lapa. specyfikacje:

• waga - trochę ponad 4 funty (1.8 kilograma)
• 3.5 cm grubości w najgrubszym miejscu
• wyświetlacz 13"
• 5 godzin pracy na baterii, więcej przy wyłączonym bluetoothu i wifi, oraz z włączonym skalowaniem cpu

parametry tego co kupił przedpremierowo pewien koleś:

• procesor: core 2 duo 2.0ghz
• ram: 1.5gb
• dysk: 60gb (7200rpm)
• wifi: 802.11 a/b/g
• bluetooth
• czytnik kart sd
• grafika: intel 945.
  

cena - w okolicach $1000.
czad. jeśli czyta to moje szefostwo: chciałbym poprosić o takie cudo zamiast della nawet zniosę gnome’a. albo doinstaluję kde.

jeśli korzystacie z ssh z pewnością zdarzyła się wam przynajmniej jedna z tych sytuacji:

1. musicie się gdzieś połączyć gdzie i tak już macie nawiązaną sesję, po to by wykonać jedno polecenie. np. : ssh root@maszynka uptime
2. musicie uruchomić wiele połączeń w jedno miejsce (konto, host, port)

do tego typu sytuacji idealnie nadaje się "connection multiplexing", znany też pod nazwą "connection sharing".
jak to działa?
jedno (pierwsze, ale nie koniecznie) połączenie ssh łączy się w trybie "master". następne połączenia w to samo miejsce używają połączenia master. dzięki temu korzystają (wszystkie) z tylko jednego połączenia tcp/ip., nie tracą czasu na negocjacje tcp/ip i ssh, ani na powtórną autoryzację.
efekt? następne połączenia są znacznie szybsze. w rozumieniu - samo połączenie. praca potem już jest ze standardową prędkością - zależną od tego jak daleko jest zdalny serwer i jak obciążone jest łącze.
ale czasem to właśnie nawiązanie połączenia jest najbardziej wkurzające i powolne.
jak więc to zestawić?
w swoim katalogu domowym macie (albo nie macie, ale wtedy trzeba założyć) katalog .ssh.
w nim trzeba stworzyć plik config. i dopisać mu na początku:
Host *
    ControlPath ~/.ssh/socket-%r-%h-%p
    ControlMaster auto

co to spowoduje? pierwsza linijka mówi, że poniższe tyczą się wszystkich połączeń.
druga - mówi, że sockety unixowe do komunikacji z połączeniem master mają być tworzone w katalogu $HOME/.ssh, a nazwa pliku ma się składać z:

• słowa "socket"
• nazwy konta na które jest połączenie
• nazwy hosta na które jest połączenie
• numeru portu na które jest połączenie

oddzielone myślnikami.
czyli gdy połączę się na konto "depesz" na maszynie kotek, to pojawi mi się taki plik:
srw——- 1 depesz depesz 0 2007-01-17 11:15 /home/depesz/.ssh/socket-depesz-kotek-22
ostatnia linijka mówi ssh, że negocjowanie połączeń lub korzystanie z mastera ma być automatyczne - jak nie ma jeszcze mastera, to aktualne połączenie ma być masterem i stworzyć socket. jak już jest master, to korzystamy z niego.

co nam to daje? przeprowadzę krótki test.
najpierw, bez mastera, połączę się na maszyne w swoim lanie i wykonam uname’a:

=> time ssh kotek uname

Linux

real    0m0.532s

user    0m0.032s

sys     0m0.000s

to teraz połączę mastera i ponowię test:

=> time ssh kotek uname

Linux

real    0m0.036s

user    0m0.020s

sys     0m0.004s

nieźle, nie? a trzeba pamiętać, że im dalej tym "szybciej" całość zadziała.
np.: do kotka mam ping w okolicach 1ms. do maszyny web którą zaraz potestuję, mam ping 12ms.
efekty?
bez mastera:

=> time ssh web uname

Linux

real    0m1.579s

user    0m0.048s

sys     0m0.004s

z masterem:

=> time ssh web uname

Linux

real    0m0.154s

user    0m0.016s

sys     0m0.000s

czy to wszystko jest "za darmo"? nie ma wad?
ma jedną, drobną.
pierwsze połączenie automatycznie staje sie masterem. i nawet jak się wylogujemy ze zdalnego hosta, to nie odzyskamy terminala, bo połączenie musi być cały czas aktywne - do czasu aż wylogujemy się ze wszystkich sesji ssh otwartych w tym połączeniu.
czyli jeśli:
na jednej konsoli zrobię ssh kotek, to to połączenie staje się masterem
na drugiej konsoli robię ssh kotek, to korzysta z połączenia mastera. odpalam tam sobie coś trwającego długo - np. backupy. to nie mogę zamknąć połączenia 1 dopóki się 2 nie skończy.
nie jest to wada wielka. trochę gorsze jest to, że jeśli zerwę (np. kill’em) pierwsze połączenie - to padają wszystkie.
to dwie wady. zyski w/g mnie mocno przeważają.
polecam każdemu zobaczenie jak to działa. warto.

drm - digital rights management.
ogólna nazwa tycząca się jakichkolwiek metod służących ochronie praw autorskich lub intelektualnych do utworów, tekstów oraz innych "obiektów" zapisanych w postaci cyfrowej.
najsłynniejsze przypadki do css (dvd-css) - system zabezpieczeń dvd, różnego rodzaju drm’y w sklepach z mp3 (np. w itunes) czy software do drm od sony który instalował w systemie rootkita i który kosztował sony ponad 15 milionów dolarów w odszkodowaniach.
czemu o tym piszę? bo alan cox - osoba dosyć znana wszystkim zainteresowanym rozwojem linuksa - jako jądra systemu, zgłosił drm jako technikę którą chce opatentować. oficjalny wniosek został złożony, czekamy na to czy patent zostanie przyznany.
po co patent? dzięki temu alan będzie mógł trzymać "w szachu" wszelkiego rodzaju firmy (riaa/mpaa/…) które chciałyby kiedykolwiek wykorzystać jakieś patenty przeciwko linuksowi.

nsa, znana kiedyś jako "no such agency", a ostatnio z aktywnego współudziału w rozwoju linuksa opublikowała pdf‘a zatytułowanego "The 60 Minute Network Security Guide (First Steps Towards a Secure Network Environment)".
całość jest dosyć spójna, tyczy się windowsów i unixów. warto przeczytać choćby po to by sprawdzić czy na pewno wszystko z tego się zrobiło.