Odo.lv serveris ir atjaunots uz Ubuntu 12.04

8.04 versiju Canonical uzturēs līdz šā gada aprīlim. Tā kā serveru ilgās uzturēšanas versijas uztur veselus piecus gadus, izvairījos no 10.04 versijas lietošanas (serveros), bet 8.04 versijas uzturēšanas beigas par sevi atgādināja jau labu laiku, kā tāds caurs zobs. 

Daudz vairāk mani uztrauc tas, ka beidzoties versijas uzturēšanas laikam, no tīmekļa diezgan ātri pazūd visas programmatūras krātuves, un uz servera vairs nevar uzstādīt jaunas programmas vai veikt kādas citas izmaiņas. Tas gan ziņkāres apmierināšanai var traucēt diezgan nopietni. Galu galā, uz odo.lv darbojas (vai ir darbojies) praktiski viss, kas ir aprakstīts padomos...

Savā laikā esmu atjaunojis vairs neuzturētu Ubuntu darbstaciju ar nepieejamu programmu krātuvi. Piesaucot visādas leģendāras personas to var izdarīt, bet tā nav nodarbe vājiem nerviem (t.i. — man).

Tāpēc vakar nolēmu, ka šis "zobs ir jāsalabo". 

Jaunu operētājsistēmu labāk ir uzstādīt pilnībā no jauna. Ja veic operētājsistēmas atjaunošanu, ir lielāka iespēja "paklupt" pret kādu mantotu neatbilstību, toties atjaunošanu var veikt mājās pie sava datora. Uzstādot operētājsistēmu pilnībā no jauna arī nav ērti — jāraksta kompaktdisks, jādodas uz datu centru, un jāņemas tā troksnī un caurvējā. (Galu galā, es tur šogad jau biju.)

Darbinot uzstādīšanas vedni attālināti ar SSH savienojumu, lielas problēmas var sagādāt tīkla savienojuma pārrāvums. Lai arī uzstādīšanas vednis turpinās strādāt, pārtrūkstot tīkla savienojumam, jūs vairs nevarat ievadīt savas (jā/nē) atbildes dažādiem jautājumiem. To var risināt, uzstādīšanas vedni palaižot ar parametru: "vienmēr teikt jā", bet pareizāk to ir palaist īpašā programmā, kurai var brīvi pieslēgties un atslēgties, tai turpinot strādāt. Es izmantoju screen. 

Canonical rekomendē pāriet no 8.04 uz 12.04, atjaunojot 8.04 uz 10.04 versiju, un tad 10.04 atjaunot uz 12.04. Es tā arī darīju. Ap 13:00 spļāvu pār kreiso plecu, pieklauvēju pie koka (galvas) un palaidu:

Ap 14:00 atjaunošanas process bija pabeigts, pārliecinājos, ka /boot/grub/menu.lst ¹ ieraksts atbilst esošam Linux kodola failam un pārstartēju serveri.

Serveris no tīkla pazuda, un pēc bezgalīgi ilga laika sāka atbildēt uz ping odo.lv, bet... ar SSH pieslēgties tā arī neizdevās...

Hmm... nolēmu, ka pirms došanās uz Rīgu jāiestiprinās, un devos pusdienās. Pēc pusdienām vēlreiz pārbaudīju veiksmi un Urrā!!! Pieslēdzos serverim no jauna. lsb_release -a lepni rāda versiju 10.04. Stundas laikā biju pārlēcis diviem gadiem. Ja neskaita dažas konfigurācijas nepilnības un sistēmas brīdinājumus, Apache tīmekļa serveris MySQL datu bāze un Tomcat5.5 lietotņu serveris turpināja strādāt. Ōkēi... tik tālu viss labi. Ņēmu nākamo kafijas krūzi un, saskaņā ar rekomendāciju migrācijai no 10.04 uz 12.04 atkal ievadīju:

Un... uzstādīšanas vednis pēc tam, kad izveidoja jaunu screen sesiju, iegāja bezgalīgā cilpā, pieprasot apstiprināt arvien to pašu... Meklējot kļūdas žurnālos un eksperimentējot, aizgāju neceļos ar SSH, bet beigās sapratu, ka kļūda, visticamāk ir saistīta ar neatrisinātu Python pakotnes atkarību, kuras dēļ Ubuntu migrācijas vednis nestrādāja kā nākas.

Te nu talkā nāca tas, ka Ubuntu ir arī Debian (tikai savādāks). Izmantoju Debian rekomendēto veidu un Python atkarības kļūdu atrisinu sekojoši. Pārliecinājos, ka /etc/apt/sources.list bija norādīts ...precise... un pildīju komandas:

sudo aptitude safe-upgrade nācās atkārtot vairākas reizes, kamēr tika atrisinātas visas atkarības un sudo aptitude full-upgrade izgāja bez kļūdām. Kopā ar iepriekšējo migrāciju nācās atbildēt uz ~40 jautājumiem par konfigurācijas izmaiņām (saglabāt esošo, vai izmantot pakotnes), ko saglabāju ekrāna izdrukās. Ap 16:30 ievilku elpu, spļāvu un citādi māžojos, un pārstartēju serveri kārtējo reizi.

Pēc mokoši garām minūtēm serveris atkal atsaucās tīklā un pēc pieteikšanās tas lepni ziņoja:

Pēc atjaunošanas strādāja:

1. Linux reģistrētie lietotāji,
2. Java lietotnes: Xwiki
3. Squirrelmail tīmekļa e-pasta klients (bet nevar pieslēgties),
4. Piwik tīmekļa statistika (kad atjaunoju datu bāzi),
5. Awstats tīmekļa statistika,
6. Munin pārraudzība (gan mezgls, gan serveris).

Vai nu tāpēc, kā migrācija nebija veikta ar Canonical svētību, vai kā savādāk, neviens daudzmaz sarežģīts serviss nestrādāja:

1. Apache tīmekļa serveris gāja, bet ar brīdinājumiem,
2. e-pasta serveri: Postfix, Dovecot
3. MySQL datu bāze
4. Tomcat Java lietotņu serveris ☹... 

Sāku ar MySQL. Tā kā tā datu bāzes man atrodas /home/mysql, tad Apparmor neļāva mainīt mapes saturu un MySQL neuzstādījās veiksmīgi. To (un principā arī visas citas kļūdas), laboju, pakotni noņemot, pārmeklējot, vai nav saglabājušies lieki konfigurācijas faili, un tad uzstādot un pielāgojot. Pārnesu Tomcat lietotnes no /var/lib/tomcat5.5/webapps uz /var/lib/tomcat7/webapps. MySQL datu bāzes pārnesu ar Mysqldump. Proftpd atjaunoju anonīmo pieeju un pasīvo portu numurus. Ap 18:40 visi tīmekļa darbībai nepieciešamie servisus biju daudzmaz "sačubinājis".

Tad ķēros klāt pie e-pasta. Neveiksmīgi centos atrisināt Postfix un Dovecot konfigurācijas neatbilstības, tāpēc beigās noņēmu visas pakotnes, izdzēsu atlikušo drazu (neizdzēstos failus), un uzstāīju no jauna. E-pasts aizgāja momentā, tikai, pagaidām, tas iet bez SASL autentifikācijas (tāpēc kā e-pasta klientu varu izmantot tikai Squirrelmail, bet nevaru Evolution).

Pirms devos gulēt, ieplānoju uz nakti ārpuskārtas rezerves kopijas. Kad agri no rīta pārbaudīju, kas noticis, kopijas bija izveidotas, bet milzīgi lielas. Atklājās arī, ka bija "uzkāries" Yacy serveris, bet tā pārbaudes skripts kļūdaini bija nokāvis arī Tomcat, ko, protams, vairs nebija palaidis. Palaidu Tomcat, atslēdzu Yacy pārbaudes skriptu un devos gulēt tālāk. Brīvdiena taču.

Šodien atjaunoju Dar skriptus (-y slēdža vietā tagad jāizmanto -z).

Atlikušās neizdarītās lietas:

1. Apache konfigurācijas brīdinājumu novēršana,
2. e-pasta SASL autentifikācija,
3. jāsalīdzina, kas ir mainījies jaunākajos konfigurācijas (*dpkg*) failos, salīdzinot ar migrētajiem,

Ja serveris atrastos blakus, tad varbūt nebūtu vērts, jo atjaunot reģistrētos lietotājus, izmainīt noklusētās konfigurācijas u.t.t., arī ir apnicīgi, toties darāmais darbs būtu prognozējamāks. Bet, ja vēlas serveri atjaunot attālināti, tad tas ir vienīgais iespējamais veids...

1. ^ Uz servera ir palikusi Grub1 versija, Grub2 izmanto /boot/grub/grub.cfg.