Wstrzymanie systemu i brak sieci w Ubuntu

Czy też zadajecie sobie to pytanie czemu w Ubuntu 14.04 prawie za każdym razem po wstrzymaniu systemu i ponownym włączeniu nie ma sieci i nie pomaga nawet wyłączenie i włączenie ikonkami na górnym pasku w Gnome?

Najszybsze rozwiązanie to ponowne wstrzymanie systemu i za chwilę jego uruchomienie guzikiem w obudowie komputera czy laptopa.

Drugie rozwiązanie jest ciekawsze, lecz jeszcze je testuję.

Otóż weryfikujemy zawartość w pliku odpowiedzialnym za konfigurację naszej karty sieciowej:

~$ cat /etc/network/interfaces

Jeśli Ubuntu podczas instalacji było konfigurowane w najprostszy sposób, a zapewne było („DHCP”, „Dalej”, itp), to najprawdopodobniej zawartość pliku z interfejsami będzie następująca:

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

Coś jest, ale widzimy, że w pierwszej linijce mamy ifup, ifdown więc sprawdzamy, bo może zadziała:

~$ sudo ifup eth0

Po podaniu hasła root’a mamy:

Ignoring unknown interface eth0=eth0.

Jak widać brak rozpoznania interfejsu eth0.

Nic więc prostszego jak dopisać (edytorem nano) odpowiednią konfigurację (dwie ostatnie linijki) zachowując pobieranie adresacji metodą dhcp:

~$ sudo nano /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

Zapisujemy plik i ponownie podnosimy interfejs eth0:

~$ sudo ifup eth0

Wtedy otrzymujemy :

Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/00:25:b3:75:35:b0
Sending on LPF/eth0/00:25:b3:75:35:b0
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x3bb849d7)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 (xid=0x3bb849d7)
DHCPREQUEST of 192.168.0.32 on eth0 to 255.255.255.255 port 67 (xid=0x3bb849d7)
DHCPOFFER of 192.168.0.32 from 192.168.0.1
DHCPACK of 192.168.0.32 from 192.168.0.1
RTNETLINK answers: File exists
bound to 192.168.0.32 -- renewal in 2296766 seconds.

Interfejs eth0 jest podniesiony natomiast ikonka w pasku Ubuntu pokazuje połączenie, ale generalnie łącze mamy przywrócone.

Testując kilka przypadków wychodzi na to, że rozwiązanie nie działa z automatu za każdym razem. Wtedy należy w konsoli ręcznie wykonać:

~$ sudo ifdown eth0
~$ sudo ifup eth0

Jeszcze tylko ikonka sieci mogłaby prawidłowo wskazywać połączenie.

Edytujemy (jednorazowo) plik resolv.conf pod kątem wskazania DNSów Google:

~$ echo -e "nameserver 8.8.8.8\nnameserver 8.8.4.4" | sudo tee /etc/resolv.conf

Na koniec restart network managera (ikonka sieci na pasku):

~$ sudo service network-manager restart

Powodzenia!

 

Dodatek:

Aby nie trzeba było tego wszystkiego ręcznie uruchamiać, tworzymy skrypt siec.sh np. poleceniem

~$ nano ./siec.sh

którego zawartość przedstawia się następująco:

#!/bin/bash
sudo ifdown eth0
sudo ifup eth0
sudo service network-manager restart

Po zapisaniu pliku należy nadać uprawnienia do uruchomienia, najlepiej tylko dla właściciela, czyli

~$ chmod 700 ./siec.sh

Jak już mamy gotowy skrypt, który po uruchomieniu poprosi tylko o hasło root’a, to możemy przystąpić do utworzenia ikonki (skrótu) na pulpicie Ubuntu, czyli tzw. aktywatora. Wpierw należy zainstalować (o ile nie jest) program do tworzenia aktywatorów poleceniem

~$ sudo apt-get install --no-install-recommends gnome-panel

Następnie należy wywołać program z opcją tworzenia nowego aktywatora

~$ gnome-desktop-item-edit ~/Pulpit/ --create-new

Otworzy się okienko z możliwością podania nazwy, polecenia (pełnej ścieżki do skryptu wybieranego guzikiem Przeglądaj), komentarza oraz ikonki.

Klikając dwukrotnie utworzonego aktywatora na pulpicie Ubuntu, otrzymamy okno konsoli, w którym system poprosi użytkownika o hasło (wywołane poleceniem sudo ze skryptu).

Działa, ale to nadal nie jest automat, który powinien być zaimplementowany w Ubuntu w sytuacji wybudzenia komputera ze stanu wstrzymania (suspend mode).

Powodzenia!

Brak zegara w Ubuntu i problemy z ikonami w Unity

Natrafiłem dzisiaj na ciekawy problem, gdyż po załadowaniu i zalogowaniu się do systemu Ubuntu 14.04 zauważyłem, że w górnym pasku zabrakło… zegara.

W pośpiechu zacząłem szperać w sieci co mogło się stać, lecz natrafiłem tylko na propozycje włączenia Unity lub reinstalacji indicator-datetime.

Spokojnie mogę powiedzieć, że najszybszym rozwiązaniem odświeżającym Unity w Ubuntu jest polecenie:

sudo killall unity-panel-service

Po chwili zobaczyłem wszystkie ikonki wraz z zegarem.

Powodzenia!

Skaner dokumentów w sieci lokalnej

Oto kolejne kroki aby mieć możliwość skanowania dokumentów np. na drukarce wielofunkcyjnej pracującej w sieci lokalnej i posiadającej stały adres IP, np. 192.168.1.10.

W terminalu Ubuntu wpisujemy

sudo gedit

Mamy uruchomiony edytor tekstu z prawami admina aby móc zapisać zmieniony później plik.
Następnie w edytorze wyszukujemy plik do otwarcia

/etc/sane.d/xerox_mfp.conf

Na końcu pliku dopisujemy jedną linijkę (można też dodać jakiś komentarz dla porządku)

tcp 192.168.1.10

Adres IP wskazuje oczywiście na urządzenie z przypisanym adresem IP.

Od teraz delektujemy się skanowaniem dokumentów na urządzeniu wpiętym do sieci lokalnej.

VirtualBox i problemy z portami USB w Ubuntu

Jakże cudnym darmowym narzędziem jest VirtualBox ze stajni Oracle. Zaiście cudnym, jednakże niejedna osoba zastanawiała się czemu po wpięciu pendrive lub karty pamięci SD/MicroCD nie widać jej w naszej wirtualce (w menu Urządzenia > Urządzenia USB jest info o niedostępności)…

Gdyby ktoś wciąż nie mógł znaleźć odpowiedzi u wujka Google, poniżej podaję rozwiązanie tego problemu.

Generalnie chodzi o to, że uruchamiany VirtualBox korzysta z grupy użytkowników o nazwie vboxusers tworzonej podczas instalacji tego oprogramowania.
Wynika to z braku odpowiednich uprawnień dla użytkownika (u mnie adam), na którym aktualnie pracujemy w Ubuntu, a który to użytkownik uruchamia aplikację VirtualBox.

W sieci jest kilka artykułów mówiących o tym, że należy zainstalować specjalny programik do zarządzania grupami użytkowników w Ubuntu.
Jednakże od wersji 12.04 nie ma już tego programiku, ale spokojnie, przecież wciąż mamy konsolę 🙂

Nic trudnego, odpalamy terminal i podajemy polecenie (w trybie sudo więc i podajemy hasło root’a):

sudo gedit /etc/group

lub zamiast edytora gedit, w trybie tekstowym można podać nano, vim lub jakikolwiek inny np. mcedit.

Szukamy teraz grupy vboxusers. U mnie był taki zapis (akurat ostatni wiersz)

vboxusers:x:127:

Jak dodać naszego użytkownika do tej grupy?
Po dwukropku podajemy nazwę użytkownika, np. adam

vboxusers:x:127:adam

Teraz nie pozostaje już nic innego jak tylko zapisać wszystkie prace w innych aplikacjach i pootwieranych oknach a w naszym terminalu wpisać na koniec

sudo reboot

podając hasło root’a.

Teraz odpalając naszą wirtualkę mamy już dostęp do portów USB.
Co ciekawe, gdy wybierzemy odpowiedni port USB (w ustawieniach uruchomionej wirtualki), taka wirtualka jakby zabiera nam ten zasób, tzn. znika z Ubuntu a pojawia się np. w Windows, jeśli wirtualka zawiera system Widnows.

Ale co tam, ważne, że w tej wirtualce mam pendrive 🙂

Enjoy! 🙂

PHP: syntax error, unexpected $end

Dla zdezorientowanych, w przypadku pojawienia się błędu o podobnej treści:

Parse error: syntax error, unexpected $end in /usr/home/test/application/views/v_main.php on line 1731

Najlepiej jest nie panikować.
Wiemy, że kod jest poprawny, wiemy, że błąd ten generowany jest gdy mamy niepełny kod i brakuje klamer zamykających.

Rozwiązanie:
edytujemy na serwerze plik php.ini i ustawiamy zmienną:

short_open_tag = On

i już.

VirtulBox i mała rozdzielczość w oknie Ubuntu

Zapewne znane jest Wam potężne narzędzie VirtualBox, dzięki któremu można uruchamiać aplikacje i programy na innych systemach operacyjnych aniżeli bieżącym.

Naszło mnie ostatnio na uruchomienie wielu instancji VBOX przy czym każda z nich posiada inną dystrybucję Linux/Unix (oczywiście OpenSource/GNU).
Kiedyś, gdy VBOX było niezależnym narzędziem (nie ze stajni Oracle), w sieci dostępne były na tyle proste dystrybucje systemów OpenSource, że po czystej instalacji sterowniki do kart graficznych automatycznie konfigurowały i ustawiały największą rozdzielczość uzależnioną od przydzielonej w VirtualBoxie pamięci grafiki (tak przynajmniej było u mnie).
Natomiast obecnie po czystej instalacji systemu np. Ubuntu dostaje się dość małe okienko (800x600px) z defaulta.

Problem pojawia się w momencie gdy chcemy zwiększyć rozmiar tego okienka i jednocześnie zyskać nieco na wolnej przestrzeni pulpitu.

Oczywiście zaglądamy do ustawień Ubuntu:

System -> Preferencje -> Monitory

lecz niestety mamy słabe możliwości:

- 800×600 (4:3)
- 640×480 (4:3)

Pomyślałem sobie: aha, dałem za mało pamięci Video dla instancji VBOXa. W starszych wersjach VBOXa i Linux/Unix im więcej pamięci przydzielałem, tym większą rozdzielczość mogłem ustawić w VirtualBox (testowałem na sławnym Redhat Manhattan).
Jednak w moim obecnym przypadku gdy dałem 512MB dla grafiki VBOX, nadal nie mogłem zwiększyć rozdzielczości w wirtualce Ubuntu 11.04.
W Windows mając tyle pamięci video można spokojnie ustawić przynajmniej 1600x1200px.
Poszperałem trochę w Google i okazało się, że od którejś wersji VBOX ma takie cudo jak:

VBoxGuestAdditions.iso (43,37 MB)

Jeśli chcemy zwiększyć rozdziałkę w wirtualce należy zainstalować dodatki VirtualBox (dostępny razem z Oracle VirtualBox).
Jednak zanim zamontujemy dodatki powinniśmy przygotować system do tego - w Ubuntu z poziomu konsoli instalujemy pakiet DKMS:

sudo apt-get install dkms

Gdy zapytaj o hasło, podajemy hasło SuperUsera (tj. root’a).
Następnie montujemy ISO bezpośrednio w VBOX:

menu: Urządzenia -> Zainstaluj Dodatki (Guest Additions)

Ubuntu powinien wykryć nośnik automatycznie i wyświetlić okienko z pytaniem o uruchomienie.
Intuicyjnie wybieramy odpowiedzi twierdzące i po chwili Additions są już zainstalowane (konfigurowane są moduły kernela odpowiedzialne m.in. za resolution).
Jeśli nie uda się jakoś automatycznie tego zainstalować, to w konsoli można uruchomić jako root oczywiście znajdując się w katalogu głównym zamontowanego ISO:

sudo sh ./VBoxLinuxAdditions.run

Do pełni szczęścia potrzebny jest reset instancji wirtualki poprzez restart Ubuntu (z ikonek systemowych wystarczy).

Powyższe czynności instalują w instancji rozszerzone sterowniki m.in. grafiki dające więcej możliwości, np. możliwość zmiany rozdzielczości pulpitu naszej wirtualki.
W moim przykładzie - Ubuntu 11.04 Niebiańska Nimfa - od razu po restarcie miałem duże okno z wirtualką (ustawiona była od razu rozdzielczość maksymalna z możliwych, np. 1440x1050px).

Więcej informacji znajdziecie na stronie manuala do VirtualBox: .

kernel: panic: ffs_blkfree: freeing free block

Po zainstalowaniu czyściutkiego nowego systemu FreeBSD 8.0-RELEASE, pracując już po SSH (putty) podczas instalowania odpowiednich portów (polecenie: make install clean), system zaczął się dziwnie i niestabilnie zachowywać. Skutkiem niestabilności były restarty systemu w zasadzie z niewyjaśnionych przyczyn.
Przykład: port się kompiluje i nagle restart, putty traci łączność z serwerem, ponownie zalogowanie do systemu, sprawdzenie uptime, gdzie z reguły było kilka sekund/minut. Na koniec dmesg, który potwierdzał restart serwera.
Po każdym restarcie szukałem informacji w logach (/var/run, /var/log). Jedynie co znajdywałem to informację o restarcie.
Ciekawostką było to, że restarty pojawiały się w dowolnym momencie i tylko podczas pracy dysku (read/write). A czasami w logach nie widać nieprawidłowej pracy dysków.
Nieufność do nowych dysków Caviara (tylko 320GB) pokierowały moją intuicją, aby sprawdzić logi S.M.A.R.T. (portem smartmontools). Ale niestety, niczego złego tam nie znalazłem (No Errors Logged).
Zmieniłem kable. Żadnych zmian. Podłączyłem monitor i… przy restartach miałem coś takiego:

Jan 19 09:13:41 fox syslogd: kernel boot file is /boot/kernel/kernel
Jan 19 09:13:41 fox kernel: dev = ad0s1f, block = 1, fs = /usr
Jan 19 09:13:41 fox kernel: panic: ffs_blkfree: freeing free block
Jan 19 09:13:41 fox kernel: cpuid = 0
Jan 19 09:13:41 fox kernel: Uptime: 44m25s
Jan 19 09:13:41 fox kernel: Cannot dump. No dump device defined.
Jan 19 09:13:41 fox kernel: Automatic reboot in 15 seconds - press a key on the console to abort
Jan 19 09:13:41 fox kernel: Rebooting…

Może powinienem ustawić inny poziom logowania demona syslogd? Może wtedy zobaczyłbym powyższe zapisy w logach?
Jednakże z powodu braku czasu zarzuciłem temat wyszukiwarce google.
Okazało się, że freeing free block podczas pracy systemu i dysku, to bug samego systemu, z którym już od kilku lat borykają się autorzy dystrybucji freeBSD.
Wg ich sugestii należało wyłączyć tzw. softupdates dla danego systemu plików (u mnie native freebsd -> ufs).
Podobno softupdates przyspiesza pracę na dysków zwalniając odpowiednie bloki (freeing free blocks) wg zaawansowanych algorytmów.
Sprawdziłem więc jak było u mnie:

fox# mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local, multilabel)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, local, soft-updates)
/dev/ad0s1d on /var (ufs, local, soft-updates)

Postanowiłem wyłączyć softupdates dla /usr, na którym występował problem.
Nie można tego było zrobić on-the-fly (podczas pracy systemu), ponieważ /usr była w użyciu, a fix można wykonać tylko i wyłącznie na odmontowanej partycji. Jedyna droga to boot‚owanie systemu w trybie Single user mode.
Polecenie

#tunefs -n disable /usr

wyłącza softupdates na /usr.
Jeszcze szybko sprawdziłem aktualny stan ustawień systemu plików

fox# mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local, multilabel)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, local)
/dev/ad0s1d on /var (ufs, local, soft-updates)

i reboot.
Jakoś do dzisiaj nie widać wyraźnego spadku wydajności pracy dysku po wyłączeniu softupdates.
Ważniejszym jest, że restartów już nie ma. Nic tylko się cieszyć.
Jako ciekawostkę mogę dodać, iż serwerów freeBSD postawiłem już całkiem sporo, a taki przypadek pojawił się po raz pierwszy.
Może to jednak ten Caviar? Może powinienem wybrać Seagate albo Maxtor? 🙂

p.s. polecam też HandBook‚a freeBSD o Tuning Disks: http://www.freebsd.org/doc/handbook/configtuning-disk.html

panic: ufs_dirbad i restarty freeBSD

Dobry administrator zawsze i dokładnie czyta logi, z akcentem na dokładnie :).

Kilka dni temu miałem dość ciekawy przypadek automatycznego restartu serwera na skutek wykonywania prostych poleceń, np. find lub locate.
Co ciekawsze, serwer „wywalał” się zawsze na tym samym katalogu. Z początku myślałem, że to wina usługi samba i udostępnionych plików/katalogów, jednak po wnikliwym wczytaniu się w logi systemowe, przekonałem się, że byłem w błędzie.

Błąd był widoczny już w samym dmesg (logi systemowe)

/dev/ad0s1: bad dir usr 25789343 AT OFFSET 1024: MANGLED ENTRY
panic: ufs_dirbad: bad dir

Z tego wynika, że mamy do czynienia z wadliwym katalogiem usr.

Niby prosta rzecz, wchodzimy do single user mode (wtedy dyski/partycje nie są zamontowane).
Sprawdzamy tzw. mount point poleceniem

cat /etc/fstab

i traktujemy zamontowaną etykietkę (label) jako katalog /usr poleceniem fsck

# fsck -y /dev/ad0s1f

(u mnie /usr jest zamontowany jako ad0s1f).

Na koniec skanowania powinno nam się wyświetlić

***** FILE SYSTEM MARKED CLEAN *****

Po ponownym uruchomieniu serwera sprawdzamy czy wszystko jest OK przykładowymi poleceniami

# find / -type d -exec ls -ld {} ;
# find / -type d -exec stat {} ;
# find / -type d -exec touch {}/mydummyfilenamewhichshouldnotexist ;

Najwyraźniej fsck nie poradziło sobie z tym dziwnym przypadkiem, ponieważ freeBSD nadal się restartuje (panic) podczas wykonywania powyższych testów.

Na szczęście jest sposób aby to naprawić, ale może wystąpić sytuacja, że z uszkodzonego katalogu nie odzyskamy danych, aczkolwiek bądźmy dobrej myśli i miejmy pewność, że mamy zrobioną wcześniej kopię zapasową tych danych. Istotą rozwiązania problemu jest naprawienie systemu plików i wyeliminowanie samoistnych restartów systemu freeBSD.

Będąc ponownie w trybie single user mode uruchamiamy narzędzie fsdb (FileSystem DeBugger)

# fsdb /dev/ad0s1f
** /dev/ad0s1f
Editing file system ‚/dev/ad0s1f’
Last mounted on /mnt/ad0s1f
(…)
fsdb (inum: 2)>

Teraz wpisujemy numer tzw. inode, który bierzemy z loga (u mnie był to numer 25789343)

fsdb (inum: 2)> inode 25789343
current inode: directory
I= 25789343 MODE=40777 SIZE=1024
BTIME=May 9 12:52:12 2008 [0 nsec]
MTIME=May 9 12:52:12 2008 [0 nsec]
CTIME=May 9 12:52:12 2008 [0 nsec]
ATIME=May 9 12:52:12 2008 [0 nsec]
OWNER=root GRP=WHEEL LINKCNT=2 FLAGS=0 BLKCNT=4 GEN=157338b7
fsdb (inum: 25789343)>

Nawet gdy stracimy dane, będziemy mieli pewność, że problem zostanie usunięty.
Poleceniem clri debugując inode’a oznaczamy go jako błędny

fsdb (inum: 25789343)> clri 25789343

Wychodzimy z narzędzia debugowania.

fsdb (inum: 25789343)> quit

**** FILE SYSTEM STILL DIRTY *****
*** FILE SYSTEM MARKED DIRTY
*** BE SURE TO RUN FSDK TO CLEAN UP ANY DAMAGE
*** IF IT WAS MOUNTED, RE-MOUNT WITH -u -o reload

Będąc nadal w single user mode uruchamiamy ponownie fsck

# fsck -y /dev/ad0s1f

** /dev/ad0s1f
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
UNALLOCATED I= 25789343 OWNER=root MODE=0
SIZE=1024 MTIME May 9 12:52:12 2008
NAME=/_new2????

REMOVE=YES

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counters
(…)

Podczas skanowania pojawiały się jeszcze inne różne błędy, które naprawiały się automatycznie dzięki parametrowi -y, np.

LINK COUNT DIR I=2 OWNER=root MODE=40777
SIZE=1024MTIME=May 9 12:52:12 2008 COUNT 21 SHOULD BE 20
ADJUST? yes
(…)
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes
(…)
SUMMARY INFORMATION BAD
SAVLAGE? yes
(…)
BLK(S) MISSING IN BIT MAPS
SALVAGE? yes

Na końcu pojawił się komunikat

***** FILE SYSTEM MARKED CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****

Ale czy to wszystko? Zdecydowanie tak.
W moim przypadku było dużo szczęścia i wszystkie dane były na swoim miejscu.
Po prostu fsck jakimś dziwnym trafem nie potrafił poradzić sobie z błędnym inode o numerze 25789343.
Oczywiście ponownie przetestowałem find’em czy przypadkiem coś jeszcze nie zostało do naprawienia. Tym razem wszystko było jak należy.
Jednak gdyby nadal były restarty typu panic: ufs_dirbad: bad dir, proponuję powyższe czynności powtórzyć dla każdego złego inode’a.

Pozdrawiam

amavisd nie startuje - błąd z portem 10024

Jakiś czas temu miałem przyjemność borykać się z dziwnym problemem pakietu AMaViS’a komunikującego się z Postfix’em na portach 10024 (nasłuchiwanie AMaViS’a) i 10025 (wysyłanie odpowiedzi do Postfix’a).

Przy uruchamianiu procesu amavisd pojawia się błąd:

fox# /usr/local/etc/rc.d/amavisd start
ERROR: MISSING REQUIRED BASIC MODULES:
IO::Wrap
IO::Stringy
Unix::Syslog
Compress::Zlib
MIME::Entity
MIME::Parser
Net::Server
Net::Server::PreFork
BEGIN failed-compilation aborted at /usr/local/sbin/amavisd line 232.

Dziwnym trafem (to zapewne sprawka upgrade’owania innych portów) brakuje kilku modułów Perl’a do prawidłowego funkcjonowania pakietu AMaViS.

By rozwiązać ten problem należy wejść do konsoli Perl’a poleceniem:

perl -MCPAN -e shell

i w CPAN’ie (konsola Perl’a) instalujemy brakujące moduły (z listy powyżej) zgodnie z poleceniem

install [nazwa modułu], np. install Net::Server

Po ponownym skompilowaniu brakujących modułów (startując amavisa można zweryfikować jakich jeszcze brakuje) sprawdzamy czy nasz proces działa:

fox# /usr/local/etc/rc.d/amavisd start
Starting amavisd.
Problem in Amavis::DKIM code: Can’t locate Crypt/OpenSSL/RSA.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.9/BSDPAN /usr/local/lib/perl5/site_perl/5.8.9/mach /usr/local/lib/perl5/site_perl/5.8.9 /usr/local/lib/perl5/5.8.9/mach /usr/local/lib/perl5/5.8.9) at (eval 99) line 25.
BEGIN failed-compilation aborted at (eval 99) line 25.

Wydawać się mogło, że ponowna instalacja brakujących modułów rozwiąże problem, a tu jednak zonk.

Wobec powyższego wynika, że wsiąkł również specjalny moduł odpowiedzialny za realizację tzw. DomainKeys Identified Mail (DKIM).
Doinstalowujemy więc port

cd /usr/ports/
make search name=mail-DKIM
(…)
cd /usr/ports/mail/p5-Mail-DKIM
make install clean

I ponownie sprawdzamy czy amavisd działa

fox# /usr/local/etc/rc.d/amavisd start
Starting amavisd.
Problem in antispam SA code: Can’t locate Mail/SpamAssassin.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.9/BSDPAN /usr/local/lib/perl5/site_perl/5.8.9/mach /usr/local/lib/perl5/site_perl/5.8.9 /usr/local/lib/perl5/5.8.9/mach /usr/local/lib/perl5/5.8.9) at (eval 118) line 63.
BEGIN failed-compilation aborted at (eval 118) line 63.

Teraz łapiemy się za głowę, bowiem okazuje się, że brakuje SA (SpamAssasin’a).

Wchodzimy ponownie do konsoli Perl’a i instalujemy SA

perl -MCPAN -e shell
install Mail:SpamAssassin

Po instalacji SA uruchamiamy proces amavisd kolejny raz aby przekonać się czy jest już wszystko OK.

fox# /usr/local/etc/rc.d/amavisd start
Starting amavisd.

i sprawdzamy czy widać proces

fox# ps aux | grep amavisd
vscan 83335 3.1 3.5 79112 72304 ?? Ss 10:02AM 0:08.15 amavisd (master) (perl)
vscan 83351 0.7 3.6 82116 75068 ?? I 10:03AM 0:01.22 amavisd (ch1-avail) (perl)
vscan 83352 0.0 3.5 79744 72304 ?? I 10:03AM 0:00.03 amavisd (virgin child) (perl)
root 83359 0.0 0.0 1632 844 p0 RL+ 10:03AM 0:00.00 grep amavisd

fox# /usr/local/etc/rc.d/amavisd status
amavisd is running as pid 83335 83351 83352.

Hurra, jest sukces! Udało się! Ale… czy na pewno?
Proces działa, ale poczta nie zostaje dostarczona.

Patrzymy na logi Postfix’a

tail -f /var/log/maillog

i starając się wysłać dowolnego maila widzimy w logach następujące błędy

Oct 13 05:36:16 fox amavis[25159]: (25159-14) (!!)TROUBLE in check_mail: delivery-notification FAILED: temporarily unable to send DSN to : 450 4.4.1 Can’t connect to INET4 socket 127.0.0.1: Connection refused, MTA([127.0.0.1]:10025), id=25159-14 at /usr/local/sbin/amavisd line 11386.
Oct 13 05:36:16 fox amavis[25159]: (25159-14) (!)PRESERVING EVIDENCE in /var/amavis/tmp/amavis-20091013T030230-25159
Oct 13 05:36:16 fox postfix/smtp[29075]: 5FF9B6D42B: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1689, delays=1683/0.01/0.01/5.9, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=25159-14, delivery-notification FAILED: temporarily unable to send DSN to : 450 4.4.1 Can’t connect to INET4 socket 127.0.0.1: Connection refused, MTA([127.0.0.1]:10025), id=25159-14 at /usr/local/sbin/amavisd line 11386. (in reply to end of DATA command))

Oct 13 06:05:14 fox amavis[28132]: (28132-10) (!)FWD via SMTP: -> , 450 4.4.1 Can’t connect to INET4 socket 127.0.0.1: Connection refused, MTA([127.0.0.1]:10025), id=28132-10
Oct 13 06:05:14 fox amavis[28132]: (28132-10) Blocked MTA-BLOCKED, -> , Message-ID: <[email protected]>, mail_id: i8vzB+cdas+V, Hits: -2.235, size: 7058466, 127353 ms
Oct 13 06:05:15 fox postfix/smtp[29514]: 2B90C6D425: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=21915, delays=21778/9.7/0.02/127, dsn=4.4.1, status=deferred (host 127.0.0.1[127.0.0.1] said: 450 4.4.1 id=28132-10 - Temporary MTA failure on relaying, Can’t connect to INET4 socket 127.0.0.1: Connection refused, MTA([127.0.0.1]:10025), id=28132-10 (in reply to end of DATA command))

Z powyższych błędów wynika, że jest jakiś problem przy połączeniu na porcie 10024.
Tutaj przyznam się bez bicia, że w configu Postfix’a zmieniłem wcześniej w celach testowych port z 10024 na 10025.

Aby nie mieszać, ustawienia plików konfiguracyjnych powinny być następujące

amavisd.conf

# Port na którym będzie nasłuchiwał AMaViS:
$inet_socket_port = 10024;
# Dopuszczaj połączenia jedynie poprzez lokalny adres IP:
@inet_acl = qw( 127.0.0.1 );

main.cf

# AMaViS
content_filter=smtp-amavis:[127.0.0.1]:10024

master.cf

smtp-amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes

127.0.0.1:10025 inet n - n - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000

Po doprowadzeniu konfiguracji pakietów Postfix + AMaViS do porządku, wszystko wróciło do normy

Oct 13 06:45:44 fox postfix/cleanup[83006]: 7DDC36D41B: message-id=<000d01ca6824$a61bc6b0$6400a8c0@morozov>
Oct 13 06:45:44 fox postfix/qmgr[38715]: 7DDC36D41B: from=, size=10257, nrcpt=1 (queue active)
Oct 13 06:45:44 fox amavis[80899]: (80899-04) (!!)WARN: all primary virus scanners failed, considering backups
Oct 13 06:45:49 fox postfix/smtpd[83003]: disconnect from unknown[113.169.91.43]
Oct 13 06:45:50 fox amavis[80899]: (80899-04) Blocked SPAM, [113.169.91.43] [113.169.91.43] -> , quarantine: spam-gAJtMJQua0NH.gz, Message-ID: <000d01ca6824$a61bc6b0$6400a8c0@morozov>, mail_id: gAJtMJQua0NH, Hits: 14.836, size: 10257, 11290 ms
Oct 13 06:45:50 fox postfix/smtp[83007]: 7DDC36D41B: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=13, delays=1.6/0/0.01/11, dsn=2.5.0, status=sent (250 2.5.0 Ok, id=80899-04, DISCARD(bounce.suppressed))
Oct 13 06:45:50 fox postfix/qmgr[38715]: 7DDC36D41B: removed
Oct 13 06:45:55 fox postfix/anvil[83004]: statistics: max connection rate 1/60s for (smtp:113.23.24.227) at Oct 13 06:45:44
Oct 13 06:45:55 fox postfix/anvil[83004]: statistics: max connection count 1 for (smtp:113.23.24.227) at Oct 13 06:45:44
Oct 13 06:45:51 fox postfix/anvil[83004]: statistics: max cache size 1 at Oct 13 06:45:44

Po takim długim leczeniu choroby nasuwa się myśl: uwaga na upgrade portów 🙂
3mam kciuki. Pozdrawiam.

Windows Vista bootmgr - file not found

Szczęśliwi posiadacze systemu Windows Vista pewnie nie raz natknęli się na problemy związane z prawidłowym startem systemu.
Przyczyn może być wiele. Moja sytuacja była dość śmieszna, wręcz głupia.
Przez przypadek wyłączyłem nogą UPSa, pod którego był podłączony calutki zestaw komputerowy.
Po włączeniu wszystkiego na ekranie miałem napis w stylu:

Booting ‚Windows Vista’
acpi
Vista Loader 2.1.2
Done!
fallback 1
find -set-root /bootmgr

Error 17: File not found
Booting ‚Windows NT/2000/XP’

fallback 2
find -set-root /ntldr

Error 17: File not found
Booting ‚Enter Command Line’

Boot failed! Press Enter to enter command line.

Są 3 możliwości.

1) reinstalacja całego systemu w płytki instalacyjnej (dla mniej zaawansowanych użytkowników)

2) uruchomienie systemu z płytki instalacyjnej i przejście do wiersza poleceń, gdzie możemy wykonać następujące czynności:

bootrec.exe /fixmbr
bootrec.exe /fixboot

lub jeśli to nie pomoże, to w ostateczności:

X:\boot\bootsect.exe /nt60 ALL /force

gdzie X, to litera dysku, na którym znajduje się instalacja Visty

inny sposób:

expand bootmgr temp
attrib bootmgr -s -r -h
del bootmgr
ren temp bootmgr
attrib bootmgr -a +s +r +h

W tym momencie stary bootmgr jest nadpisywany przez oryginalny z płytki instalacyjnej i możemy uruchomić nasz system bez żadnych problemów.
Trzeba jednak pamiętać, że bootmgr na płytce jest nieaktywowany, tzn. że po uruchomieniu systemu naszą Vistę należy ponownie aktywować.
W tym momencie przydałby się klucz licencji. 🙂

3) ręczne uruchomienie Visty za pomoca poleceń w GRUBie

title Load bootmgr [etykietka]
root (hd0,0) [definicja ścieżki głównej]
chainloader (hd0,0)/bootmgr [załadowanie boot managera]
boot [start bootowania systemu]

i też powinno zadziałać.

Powodzenia.