PISKVOR: Mam skripty na to, co je vyhodne skriptovat. Ale deployovaci kolecko znamena "udelat balicek, nahrat tar.gz na server, nahrat ebuild na server" (jeden skript na jednom pocitaci) a "dat update;emerge -DuN world; /etc/init.d/produkt restart" na produkci (druhy skript na druhem pocitaci).

Vzhledem k tomu, ze ne vzdy se restart hodi a projiti zavislosti nejakou dobu trva a kopirovani balicku taky, navic casto zmena muze zasahnout vic balicku (system jich ma par desitek) a je dobre ji publikovat naraz a zaroven to taky lidi pouzivaji, tak neni dobre mit svazano nasazovani s vyvojem. Takze si vesele programuju, kdy se to hodi me a nasazuju, kdy se to hodi zakaznikum.

Ten git na produkci je naprosto nesvazany s jinymi repozitari a neni duvod je provazovat, v normalnim provozu jsou commity pouze typu "upstream verze", tyhle divokosti se deji jen zridka. A obcas zasahuji povicero balicku a je zajimavy az konecny vysledek a ne co vsechno zakaznik chtel vyzkouset a pak zavrhnul.

GILHAD: A na to nemas skript, kterej to deployovaci kolecko udela automagicky, kdyz commitnes neco na gitu do vetve "master" (nebo "release", nebo co tam mas)? Ja myslel, ze to uz je dneska skoro samozrejmost. Aspon teda ze tu nepadlo F-word (to na tri pismenka).

vyzkoušim tenhle script http://code.google.com/p/git-sync/
sice mi ty nový soubory(na produkci) nevypíše, ale rovnou jimi zpětně updatne ty z dev. verze, ale s trochou snahy by se to dalo přiohnout.

Jinak jednu git repository mám v té dev. verzi projektu. Používám občas před nějakými úpravami, kdy se bojim že něco rozbiju a budu muset rychle vrátit. Při syncu se do prod. verze kopíruje i tenhle .git adresář/repozitář, takže nějaký porovnávání mězi nimi asi nepřipadá v úvahu, když jsou stejný(?)

Je pravda že git používám dost povrchně, možná že to co potřebuju zvládá levou zadní. Budu ho muset trochu nadrtit.

Ja to delam tak, ze mam i na te produkcni nahozeny git (s prislusnyma .gitignore) a po nasazeni vzdy commitnu zmeny, ze "upstream x.y.z". A pred nasazovanim git status, git diff, a hned je videt, kam a jak se sahalo (a snadno se to copy+paste prenese na ten dev, nebo kamkoli jinam)

(Jo, v nekterych pripadech fakt saham na produkcni, zvlast, kdyz si nekdo vzpomene, ze nutne prave ted (pul hodiny pred navstevou zakaznika, kteremu to chce ukazat) potrebuje preformulovat nejake texty nebo prebarvit nejake barvy ve webovkach a ze se na to hned koukne a rekne co jeste dal ... tam tezko neco rozhodim prilis a delat cele kolecko s vytvarenim balicku a nasazenim, zvlast, kdyz vzapeti rekne, ze ta zelena je moc zelena a ze tam radsi teda mam dat modrou, aby nakonec usoudil, ze puvodni hneda asi byla fakt lepsi, jen by mohla byt trochu svetlejsi ... to by bylo nesmyslnych balicku az hruza ...)

Tak jsem vytvořil nový image a nainstaloval/nakonfiguroval těch pár služeb znovu, zas tak moc práce to nakonec nebylo :)

A poprosil bych o help ještě s jednou věcí: mám na jednom serveru produkční a testovací verzi jednoho projektu + script, který rsyncuje soubory z dev verze na produkční. Už se mi stalo, a obávám se že v budoucnu stane znovu, že byly na prod. verzi nějaké nové úpravy, které někdo (třeba i já:) udělal rovnou na této prod. verzi, ale ne na devel. Při syncu by to pak nedělalo dobrotu.

Vím, že s rsyncem můžu updatovat jen starší/na prod. verzi nezměněné soubory. Ale to by pak mohl vzniknout maglajz a na dev verzi by se tak úpravy z prod. stejně nedostaly. Takže bych chtěl nějak v rámci toho synchronizačního sciptu zjistit, že prod. verze obsahuje nověji modifikovaný soubory. Nejlépe teda rovnou ty soubory i rovnou vypsat, abych to mohl zkontrolovat a případně zkopčit na dev. ručně.

RATTKIN: Divný; ještě je otázka, jestlis tam neměl nějaký exotický FS - já takhle zmenšoval vfat, ntfs, ext[34], i o třeba dvacet procent, a bez problému (musí tam být pochopitelně adekvátní volný místo).

Jinak pokud máš image a tohle ti nejde, namountoval bych to rw do loopu a pustil na to gparted, ten partitions zmenšuje už úplně bez problémů.

PISKVOR: Zkouše jsem to před 3 měsíce v poslední stable clonezilla live, zkoušel jsem save disk disk - restore disk, i partition -> partition. nic mi nešlo. V reklamaci vyměnili 250g disk WD za jiného výrobce, který byl o půl mega menší, strašnej wopruz

PISKVOR: A teda bacha, Clonezilla != Clonezilla Live...

RATTKIN: Ne? Já mám dojem, že už nejmíň dva roky umí - resp. pokud děláš restore-to-disk, tak na menší disk všechny obnovovaný partitions proporcionálně zmenší. Nevím, jestli to umí i v módu restore-single-partition...

PISKVOR: s clonezillou jsem vždycky měl problém, když jsem chtěl jí na menší disk, neumí resize partition (nebo možná jo, ale po nějaký super konfiguraci)

SYNTAX_TERROR, RATTKIN: Kdysi jsem to takhle řešil pomocí Clonezilly Live (nabootované uvnitř virtuálu)- starý VM zazálohovat na hosta, zálohu obnovit na menší virtuální disk. Zdlouhavé, leč funkční.

SYNTAX_TERROR: taky by se dala kopírovat patition na novou menší partition přes gparted nebo něco podobného

LUDO: tak to mi prave pripada, ze to tim byt muze. Aspon ja teda mam porad stejnej kurzor, at uz sem teba v unity, xfce nebo gnome.

PUNKREASS: temou to neni, problem sa prenasa aj medzi inymi prostrediami (JWM, Openbox, ...)

LUDO: na mne to neadresuj, ja ti neporadim, ja sem lama:] Jediny, co bych tak ja dokazal vyzkouset, je testnout jinej kurzor a nebo ho nacitat z ~/.icons

PUNKREASS: http://pastebin.com/TXzqfk5W

LUDO: spis ti nekdo poradi, kdyz sem obsah toho xorg.conf das.

Nejaky navrh jak riesit neviditelny kurzor? akcie mysi funguju spravne, len nevidim kurzor

Hybridne grafiky na laptope Intel/AMD, po instalacii FGLRX z repozitarov a spusteni "aticonfig --initial" (vytvori /etc/X11/xorg.conf) sa stal kurzor neviditelnym. V OpenGL aplikaciach (hry) ho vidim.

Ked zmazem xorg.conf tak je znova viditelny, ale zas nefunguje spravne driver - bezi na opensourcovych.

Pouzivam Debian Jessie, verzia drivera z repozitarov je fglrx-driver (1:14.9+ga14.201-2). Prostredie je KDE (kurzor nevidim ani po nabehnuti kdm). Kernel 3.16.0-4-amd64.

SYNTAX_TERROR: Udelat novy image, v nem partitions, potom nechat zalohovat data rsyncem a nasledne znovunakonfigurovat bootloader.

SYNTAX_TERROR: to máš tři potřebné dockery spojené linkem.

Online musíš být jen při pullování. Pak už to máš jako image vboxu, jen menší a strukturovanější.

Nic extra by tam byt nemelo, jen
-apache
-mysql
-postgresql
-ssh server

Ten Docker moc nechapu, ale predpokladam, ze pro praci s nim musim byt online, coz mi ne uplne vyhovuje.

SYNTAX_TERROR: máš na tom debianu něco extra? Co prostě vzít Docker a nastartovat ho s odkazem na kopii relevantních dat?

Tak se uplne nezadarilo, jeden z bodu skoncil hlaskou neco jako "resize is not implemented yet". Tak kdyby mel nekdo nejake dalsi hinty, byl bych vdecny.

Jinak me jako (asi nouzovy) reseni napadlo - mohl bych vsechny soubory z disku proste zkopirovat na ten nove nainstalovany debian (na tom novem, mensim disku)?

MRDAC_BEDEN: tak to je parada, diky!

Ahoj, mam dotaz ohledne migrace systemu.

Mam ve virtualni masine (VirtualBox) zprovozneny Debian s apachem, databazi apod. - toto vsechno uz nejak nakonfigurovano a nejakou dobu to spokojene pouzivam. Co me ale trapi je prilisna velikost toho "obrazu" virtualni masiny. Dal jsem tomu zpocatku 200GB a tedka pokazdy pri zalohach (nebo obcasnym prenaseni na jiny komp) trpim/cekam.

Co chci, je vytvorit si novy, podstatne mensi "obraz", do ktereho bych tento debian prenesl. A to tak, aby zustalo vsechno v soucasnem stavu - tedy ty nakonfigurovane databaze apod.

Jde to nejak snadno docilit? To "snadno" neni podminka, klidne se pri tom trochu zapotim, ale zase bych to nerad cely instaloval a konfiguroval znova. Ten "hardware" se nijak menit nebude (coz asi ani nejde :), pouze zmensim velikost toho virtualniho disku/obrazu.

MRDAC_BEDEN: V tohle mam trochu zmatek, podivam se na to, protoze instalace "neceho" vytvori novou verzi, instalace neceho jinyho ten starej prejmenuje na .old a jmenuje se stejne. - myslim, ze tohle dela instalace toho nvidia ovladace, dokonce po instalaci pise, ze je treba restartovat, protoze se cosi v systemu menilo.

Kazdopadne s tim starym to jede a jediny problem je, ze s novym ne. Akorat tam mi pak (po upgradu nvidia baliku z 331 na 340) prestane chodit OpenGL akcelerace - GLX nejede dle steamclienta- Xka jedou, predpokladal jsem, ze ten nvidia ovladac, asi potrebuje i ten novejsi kernel, ale jistej si tom nejsem.

Jako logicky reseni se jevi tenhle kernel proste preskocit, nicmene zajimalo by me co s tim je.

RUTHAN: pri startu by melo byt mozne vybrat puvodni kernel - s tim vse funguje?

DANYSEK: By clovek cekal, ze to maj poreseny, kdyz to do toho updatu davaj. Nicmene hral jsem s tim horem, dole.. tuhle chybu otravil, xorg.log uz byl ok, presto jsem porad koncil na black screenu s blikajicim kurzorem. V grubu jsem zaved samozrejme i ten nove zkompilovanej kernel.

Jinak ten bootlog byl starej, nemaj ho vubec zaplej, ale v novym a v dmesg jsem toho moc nevykoukal, Jediny co psalo za fail je nejaky setupcon, ktery vytuhnul ikdyz jsem spustil pres commandlinu. Jeho stejne vytuhnuti jsem nasel jako debian bug a moc nevim co s tim. Jestli to skutecne tuhle kvuli nemu? Jestli balik s nim muzu zahodit a tak? Protoze tim, ze se bug reportuje, se jaksi nic neresi..

Proste tohle je presne to co na Linuxu nesnasim nenabehnou Xka a aby clovek u toho travil hodiny, samozrejme u me je reseni ten kernel neupgradovat.