1 2 3 4 | Logi z Debiana: Status code returned 0xc0000205 NT_STATUS_INSUFF_SERVER_RESOURCES CIFS VFS: Send error in SessSetup = -12 CIFS VFS: cifs_mount failed w/return code = -12 |
http://support.microsoft.com/default.aspx?scid=kb;en-us;177078 – rozwiązanie (solution)
To nie jest problem Linuxa.
Bing prawdę Ci powie. Nowa wyszukiwarka Microsoftu naprawdę zaskakuje 
Linux Vista, obrazek znaleziony na wykop.pl
Szukając w Internecie narzędzia, które monitorowało by stan działania dysków w jednym serwerów, natrafiłem na pakiet o nazwie mpt-status. Jest to proste narzędzie, składające się z programu oraz demona, monitorującego działanie kontrolerów RAID firmy LSI, wymienionych poniżej:
- LSI 1030 SCSI RAID
- LSI SAS1064 SCSI RAID
- LSI SAS1068 SCSI RAID
- LSI SAS 3442-R SCSI RAID
Paczka zawarta jest w kilku linuksowych dystrybucjach. W Debianie instaluje się ją poleceniem:
1 | apt-get install mpt-status |
Po zainstalowaniu program odpala się poleceniem:
1 | mpt-status |
Przy pierwszym uruchomieniu może pojawić się informacja:
1 2 | open /dev/mptctl: No such file or directory Try: mknod /dev/mptctl c 10 220 |
Trzeba więc utworzyć plik reprezentujący urządzenie znakowe
1 | mknod /dev/mptctl c 10 220 |
Zapomnieć nie można o załadowaniu modułu o nazwie mptctl
1 | modprobe mptctl |
Aby moduł ładował się automatycznie podczas startu systemu, dopisujemy linijkę do pliku /etc/modules
1 2 3 | #Plik /etc/modules/
loop
mptclt |
Jeżeli tego nie zrobimy, program nie będzie działał poprawnie, a demon zostawi komunikat w logach o „nieoptymalnym statusie kontrolerala RAID”.
1 2 3 | # /var/log/messages Jun 2 09:38:47 hepa mpt-statusd: detected non-optimal RAID status Jun 2 09:48:47 hepa mpt-statusd: detected non-optimal RAID status |
Po załadowaniu mptctl i wydaniu polecenia mknod w logach powinny pojawić sie podobne informacje:
1 2 3 4 | #/var/log/messages Jun 2 11:48:46 hepa kernel: Fusion MPT misc device (ioctl) driver 3.04.06 Jun 2 11:48:46 hepa kernel: mptctl: Registered with Fusion MPT base driver Jun 2 11:48:46 hepa kernel: mptctl: /dev/mptctl @ (major,minor=10,220) |
Przykładowe informacje zwrócone przez polcenie mpt-status:
1 2 3 4 | root@hepa:~# mpt-status ioc0 vol_id 0 type IM, 2 phy, 231 GB, state OPTIMAL, flags ENABLED ioc0 phy 1 scsi_id 32 ATA ST3250620NS 3BKH, 232 GB, state ONLINE, flags NONE ioc0 phy 0 scsi_id 1 ATA ST3250620NS 3BKH, 232 GB, state ONLINE, flags NONE |
Kontroler w jednym z naszych serwerów to (Dell PowerEdge 800), według lspci -v, sprzęt prezentujący się następującą treścią:
1 2 | SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS (rev 01) Subsystem: Dell SAS 5/iR Adapter RAID Controller |
Według autora, program sprawdzony był na następujących maszynach:
Reported working hardware configuration
—————————————
Sun Fire X4100
Sun Fire X4200
Sun Fire V20z
Sun Fire V40z
Dell PE2600
Intel Server with SE7520BD2S boards
HP ProLiant DL320 G4
IBM eServer BladeCenter LS20
Strony autora programu: http://www.drugphish.ch/~ratz/mpt-status/
Parę dni temu znajomy poprosił mnie o pomoc przy uruchomieniu modułu mod_rewrite w Apache’u który dostarczony jest z Debianem. Problem przejawiał się tym, że nie działało przekierowywanie stron ładowanych modułem userdir (przykładowy adres strony: http://localhost/~uzytkownik/). Opiszę kroki jakie trzeba wykonać aby temat rozwiązać:
Najpierw sprawdźmy czy moduły rewrite i userdir są ładowane podczas uruchomienia Apache. Odpalamy funkcję phpinfo() i szukamy sekcji apache2handler, wiersza Loaded Modules. Tam, wśród różnych opcji, powinny znajdować się dwa interesujące nas pozycje (mod_rewrite oraz mod_userdir).
Jeżeli ich tam nie ma, przechodzimy do katalogu /etc/apache2/mods-enabled/, sprawdzając czy zawiera dowiązania symboliczne ładujące odpowiednie rzeczy:
1 2 3 4 | root@venoma:/etc/apache2/mods-enabled# ls -al rewrite* userdir* lrwxrwxrwx 1 root root 30 06-01 02:09 rewrite.load -> ../mods-available/rewrite.load lrwxrwxrwx 1 root root 30 05-26 18:14 userdir.conf -> ../mods-available/userdir.conf lrwxrwxrwx 1 root root 30 05-26 18:14 userdir.load -> ../mods-available/userdir.load |
Jeżeli ich tam nie ma, tworzymy je poleceniem:
1 2 3 | root@venoma:/etc/apache2/mods-enabled# ln -s ../mods-available/userdir.load root@venoma:/etc/apache2/mods-enabled# ln -s ../mods-available/userdir.conf root@venoma:/etc/apache2/mods-enabled# ln -s ../mods-available/rewrite.load |
Restartujemy Apache:
1 | /etc/init.d/apache2 restart |
i ponownie odpalamy phpinfo(). Moduły powinny być już załadowane (założyłem tutaj, że odpowiednie pliki znajdują się w katalogu /etc/apache2/mods-available/)
Teraz otwieramy plik /etc/apache2/sites-available/default. W tymże pliku szukamy linii z opcją AllowOverride w sekcji <Directory /> , aby rewrite działał poprawnie, powinna ona wyglądać tak
1 | AllowOverride All |
Kolej na konfigurację modułu userdir. Otwieramy /etc/apache2/mods-enabled/userdir.conf, w którym nie powinna pojawić się pozycja AllowOverride None. Prawdopodobnie linijka będzie wyglądała tak:
1 | AllowOverride FileInfo AuthConfig Limit Indexes |
jest to poprawny wpis.
Ponownie restartujemy Apache:
1 | /etc/init.d/apache2 restart |
W tej chwili moduł rewrite będzie działał poprawnie. Problemem może okazać się jego użycie wraz z modułem userdir. Aby wszystko działało poprawnie, trzeba odpowiednio skonstruować plik .htaccess. Musi on zawierać dyrektywę RewriteBase:
Dla adresu np. http://localhost/~felixd/ powinna ona wyglądać tak:
1 | RewriteBase /~felixd/ |
dla http://localhost/~felixd/projekt2/:
1 | RewriteBase /~felixd/projekt2/ |
Musiałem szybko zmienić prawa dla drzewa katalogów oraz plików w nich się znajdujących, z tym że katalogi miały dostać inne prawa niż pliki w nich się znajdujące. Zwykłe chmod XXX * -R nie było tym czego szukałem. Z pomocą przyszły dwa polecenia, find oraz xargs.
1 2 | felixd@mx:/sites# find . -type f -print0 | xargs -0 chmod XXX felixd@mx:/sites# find . -type d -print0 | xargs -0 chmod XXX |
Proste i skuteczne.
Szybko potrzebowałem zmienić rozmiar wielu plików na serwerze, ale tylko tych większych niż 700px. Po chwili poszukiwań znalazłem problem udało się rozwiązać:
# apt-get install imagemagick
# mogrify -resize 700> *.jpg
Tutaj mały wyciąg z dokumentacji ImageMagick:
Only Shrink Larger Images (‘
>‘ flag)
Another commonly used option is to restrict IM so that it will only shrink images to fit into the size given. Never enlarge. This is the ‘>‘ resize option. Think of it only applying the resize to images ‘greater than’ the size given (its a little counter intuitive).
Natknąłem się na mały problem podczas próby łączenia się z bazą danych używając PDO (adapeter do MySQL) + Zend Framework.
1 | Can't connect to local MySQL server through socket '/tmp/mysql5.sock' |
Jedną drogą rozwiązania tego problemu jest ustawienie zmiennej unix_socket w pliku php.ini. Jest jednak druga możliwość. Wystarczy podczas przekazywania ustawień połączenia dodać zmienną „unix_socket” i tam wpisać prawidłową wartość 
1 2 3 4 5 6 7 8 | $options = array( 'host' => 'localhost', 'username' => 'user', 'password' => '****', 'dbname' => 'db', 'unix_socket' => '/tmp/mysql5.sock' ); $db = Zend_Db::factory('Pdo_Mysql', $options); |
W moim przypadku używam plików .ini:
1 2 3 4 5 6 7 | [development] db.adapter = PDO_MYSQL db.configuration.host = localhost db.configuration.username = user db.configuration.password = passwd db.configuration.dbname = dbname db.configuration.unix_socket = /var/run/mysql/mysqld.sock |