Profiilien roaming keskitetylle palvelimelle

[Risto H. Kurppa]

Moro!

Tarkoitus ja tarve olisi yhdestä pöytäkoneesta ja kahdesta läppäristä pystyttää seuraavanlainen kotisysteemi:
-A: [k]ubuntuläppäri virtapihinä palvelimena & musiikkisoittimena jne jne
-B: [k]ubuntu-pöytäkone - no, pöytäkoneena, 'tehotyöasemana'
-C: [k]ubuntuläppäri mukana kuljetettavaksi mutta myös tietty kotona käytettäväksi

Eli ajatus olisi että kirjautuessa koneille B tai C noudettaisiin profiili palvelimelta A. Ja jos läppäri C olisi poissa verkosta eli 'reisussa', käytettäisiin viimeistä levylle jäänyttä profiilia ja taas kotiin tultaessa synkattaisiin tiedot.

Kenelläkään kokemusta tästä?
Kotipurkkapuukkoratkaisuna tulee mieleen joku 'kirjautumisen jälkeen tutki löytyykö serveri ja synkkaa datat, muuten käytä paikallista ja uloskirjautuessa sama homma' -rsync -meininki, mutta lienee tähän joku tolkumpikin versio.

Samba? SVN?


r

[Ville Pöntinen]

En tiedä profiilista... Aika määrä erilaisia asetustiedostoja.

NFS:n avulla voi /home:n mountata palvelimelta. Kaikissa koneissa on silloin oltava identtiset käyttäjätilit ts. samat UID:t ja GID:t.

Siihen läppäriin tämä ei suoraan tietenkään toimi. Paikallinen /home kun on saavuttamattomissa kun siihen mountataan palvelimen hakemisto päälle. Ehkä läppärille voisi kehitellä jotain varmuuskopiointia näiden kahden /home:n välille.

[Risto H. Kurppa]

En tiedä profiilista... Aika määrä erilaisia asetustiedostoja.

profiililla tarkoitan siis juurikin lähinnä kotikansiota, jossa on desktopin asetukset jne mitkä nyt luovat sen tunnun että käyttää samaa työpöytää

Siihen läppäriin tämä ei suoraan tietenkään toimi. Paikallinen /home kun on saavuttamattomissa kun siihen mountataan palvelimen hakemisto päälle. Ehkä läppärille voisi kehitellä jotain varmuuskopiointia näiden kahden /home:n välille.

Eli palataan jälleen tuohon rsyncciin.. On se niin väärin.. Jotenkin tuntuu kyllä ripauksen käsittämättömältä etteikö tällaiseen muka olisi mitään valmista ratkaisua - eikö tarvetta todellakaan oikiasti maailmassa ole?

r

[Ville Pöntinen]

Täältä http://expertanswercenter.techtarget.com/eac/knowledgebaseAnswer/0,295199,sid63_gci1141666,00.html löytyi tämä http://www.linuxselfhelp.com/HOWTO/LDAP-HOWTO-6.html ja tämä http://muthanna.com/quickswitch/

Pikaisen lukemisen perusteella kumpikaan ei ole ihan mitä itsekin toivoisin. Siis kotikäyttöön pöytäkone vs. läppäri.

[mgronber]

profiililla tarkoitan siis juurikin lähinnä kotikansiota, jossa on desktopin asetukset jne mitkä nyt luovat sen tunnun että käyttää samaa työpöytää

Minä jo ihmettelinkin mistä profiilista tässä puhuttiin. Tarkennus oli hyvinkin tarpeellinen.

Eli palataan jälleen tuohon rsyncciin..

Unison voisi olla vaihtoehto rsyncille. Se selviää niistäkin tilanteista joissa tiedostot ovat muuttuneet molemmissa versioissa.

[anttimr]

Eli palataan jälleen tuohon rsyncciin.. On se niin väärin.. Jotenkin tuntuu kyllä ripauksen käsittämättömältä etteikö tällaiseen muka olisi mitään valmista ratkaisua - eikö tarvetta todellakaan oikiasti maailmassa ole?

Tonttujen kaverit pääsevät (tulevaisuudessa) nauttimaan tällaisesta synkronoitityökalusta:

Conduit is a synchronization solution for GNOME which allows the user to take their emails, files, bookmarks, and any other type of personal information and synchronize that data with another computer, an online service, or even another electronic device.

http://www.conduit-project.org/wiki

Gutsyn varastoista jo löytyykin versio 0.32.

Eikös hammasratasmiehille ole mitään vastaavaa kehitteillä?

Tarkoitus ja tarve olisi yhdestä pöytäkoneesta ja kahdesta läppäristä pystyttää seuraavanlainen kotisysteemi:
-A: [k]ubuntuläppäri virtapihinä palvelimena & musiikkisoittimena jne jne
-B: [k]ubuntu-pöytäkone - no, pöytäkoneena, 'tehotyöasemana'
-C: [k]ubuntuläppäri mukana kuljetettavaksi mutta myös tietty kotona käytettäväksi

Minulla ja varmaan monella muulla on aivan samanlainen järjestely kotona. Kiinnostaa kyllä kuulla hyvistä ratkaisuista, itselläni toistaiseksi kaikki tapahtuu manuaalisesti. 

[Risto H. Kurppa]

Tonttujen kaverit pääsevät (tulevaisuudessa) nauttimaan tällaisesta synkronoitityökalusta:

http://www.conduit-project.org/wiki

Gutsyn varastoista jo löytyykin versio 0.32.

Tässä ruvetaan jo puhumaan oikeaa asiaa, loistavaa! Pistetään tutkittavien listalle (kuten myös alla mainittu unison jne)

Eikös hammasratasmiehille ole mitään vastaavaa kehitteillä?

Kiva että meitäkin huomioit Ja totisesti toivon että olisi.. Hmm.. Toisikohan KDE4 jotain kivaa mukanaan..

Minulla ja varmaan monella muulla on aivan samanlainen järjestely kotona. Kiinnostaa kyllä kuulla hyvistä ratkaisuista, itselläni toistaiseksi kaikki tapahtuu manuaalisesti. 

Näin minäkin voisin kuvitella ettei setuppi ihan täysin vieras ole..


r


edit: ehkäpä tästäkin jotain nousee: http://www.opensync.org/
Ja tästä kde-versio kitchensync: http://www.opensync.org/wiki/kitchensync - tuosta ehkä voisi jotain rakentua..
unisonista dataa: http://www.micahcarrick.com/11-07-2007/unison-synchronize-ubuntu.html (kiitos reaby vinkistä)

[mgronber]

Minulla ja varmaan monella muulla on aivan samanlainen järjestely kotona. Kiinnostaa kyllä kuulla hyvistä ratkaisuista, itselläni toistaiseksi kaikki tapahtuu manuaalisesti. 

Minulla synkataan yksi hakemistopuu kolmen tai neljän koneen välillä. Käytännössä tämä tapahtuu synkkaamalla tiedot aina saman pääpalvelimen kanssa jossa myös tehdään päivittäiset varmuuskopiot.

Omassa järjestelyssäni tapahtuu kaikki manuaalisesti tai tarkemmin sanottuna ajan käsin skriptin joka suorittaa synkkauksen. Mitenkään muuten en haluaisikaan sen toimivan sillä muuten heräisi kysymys miten Unisonin pitäisi hoitaa tilanteet joissa ilmenee konflikteja. Yksinkertaisinta on suorittaa synkkaus käsin ja varmistaa ettei konflikteja ole ja jos niitä tulee niin ne voi korjata välittömästi.

Unison ajetaan minulla parametreilla: -batch -times.

[Risto H. Kurppa]

Minulla synkataan yksi hakemistopuu kolmen tai neljän koneen välillä. Käytännössä tämä tapahtuu synkkaamalla tiedot aina saman pääpalvelimen kanssa jossa myös tehdään päivittäiset varmuuskopiot.

Kuulostaa juurikin oikialta..

Omassa järjestelyssäni tapahtuu kaikki manuaalisesti tai tarkemmin sanottuna ajan käsin skriptin joka suorittaa synkkauksen. Mitenkään muuten en haluaisikaan sen toimivan sillä muuten heräisi kysymys miten Unisonin pitäisi hoitaa tilanteet joissa ilmenee konflikteja. Yksinkertaisinta on suorittaa synkkaus käsin ja varmistaa ettei konflikteja ole ja jos niitä tulee niin ne voi korjata välittömästi.

Hmm.. Itse taitaisin haluta synkkausten toimivan automaattisesti mutta tietysti ongelmatilanteissa ilmoittaen käyttäjälle & kysyvän ratkaisua -> eli ilmeisesti unison komentoriviltä tai jotain..

r

[Risto H. Kurppa]

no, härkää sarvista, tehdään sitten sopiva skripti..

höpö höpö, tutkitaanpas tuota unisonia, se on the tool..

oletetaan serverin IP:n olevan paikallisverkossa 192.168.0.180

Eli tehdään synkkausskripti joka suoritetaan sopivassa paikassa sekä sisään & uloskirjautuessa ja oletaen että skripti onnistuu ok niin jatketaan operaatioita (esim. startx tai sit joku hibernateshutdown-juttunen.. pitääpä vielä tutkia löytyykö KDM:stä sopivaa rakoa tälle vai olisiko tolkumpi tiputtaa KDM pois jotta näkee mitä skripti tekee & sanoo..)

jos (on olemassa http://192.168.0.180/kotiverkossa.txt) {
 jos (ei onnsitu rsync -parametrit --stats --progress -e ssh 192.168.0.180:/home/${USER}/ /home/${USER} ){herjaa vähän jotain}

Seuraavin parametrein:
-h, --human-readable        output numbers in a human-readable format
-z, --compress              compress file data during the transfer
-E, --executability         preserve executability

-a, --archive  This is equivalent to -rlptgoD. It is a quick way of saying you want  recursion  and  want  to preserve  almost  everything  (with  -H  being a notable omission).  The only exception to the above equivalence is when --files-from is specified, in which case -r is not implied. Note that -a does not preserve hardlinks, because finding multiply-linked files is  expensive. You must separately specify -H.

ja a sisältää siis
-r, --recursive             recurse into directories
-l, --links                 copy symlinks as symlinks
-p, --perms                 preserve permission
-t, --times                 preserve times
-o, --owner                 preserve owner (super-user only)
-g, --group                 preserve group
--devices               preserve device files (super-user only)
--specials              preserve special files

ehdotuksia lisäparametreiksi?
Hmm.. mitenkäsmuutenottiatuota, toimiikos tämä synkkaus kertalaakista molempiin suuntiin, vai onko rsyncillä 'suunta' olemassa?

Seuraava versio olisi sitten unisonilla..

[Ville Pöntinen]

rsync toimii vaan yhteen suuntaan. Samaan scripiin voi tietty upottaa komennon joka ajaa 'vastaavan' komennon ssh:n avulla kohdekoneella.

[mgronber]

rsync toimii vaan yhteen suuntaan. Samaan scripiin voi tietty upottaa komennon joka ajaa 'vastaavan' komennon ssh:n avulla kohdekoneella.

Kyllähän tuo onnistuu rsync:llä suoraankin.

Koodia: [Valitse]

rsync [OPTION]... SRC [SRC]... [USER@]HOST:DEST
rsync [OPTION]... [USER@]HOST:SRC [DEST]

Yksisuuntaisuudestaan johtuen se ei kuitenkaan sovellu alkuperäiseen ongelmaan erityisen hyvin vaan ongelmia tulee heti jos sekä lähteessä että kohteessa on muuttuneita tiedostoja.

[Ville Pöntinen]

Koodia: [Valitse]

rsync [OPTION]... SRC [SRC]... [USER@]HOST:DEST
rsync [OPTION]... [USER@]HOST:SRC [DEST]


Totta. Itse olen vaan käyttänyt sitä aina "yhteensuuntaan" ja sitten tosiaan ssh-käskyllä "toiseensuuntaan". Helppoa jämähtää omiin (huonoihin) tapoihin, kun asiat voi tehdä monella tavalla...

[Risto H. Kurppa]

Iskin unisonin toiminaan näillä ohjeilla: http://www.micahcarrick.com/11-07-2007/unison-synchronize-ubuntu.html

Tuntuu pelaavan ok. Valitettavasti on GTK-versio, mutta no, elämä on..

Koitin muokkauksia molempiin suuntiin, nätisti tunnistaa.
Kokeilin myös mitä se tuumii jos muokkaakin molempia päitä: näyttää diffin eikä suostu tekemään mitään vaan skippaa tiedoston: tähän pitänee kiinnittää huomiota (meinaan että tarvii tulla huomatuksi tuollaiset..)

Ja jep, pelaa komentoriviltäkin ihan kivasti: samat toiminnot (itseasiassa jopa enemmän) kuin unison-gtk:ssa. SSH:n yli menee nätisti, kysyy tosin salasanan, sen kiertoa pitää tutkaista jotenkin.. Helppiä katsellessa näyttäisi että unison osaa jopa pitää varmuuskopioita noista synkkauksista mikä ei välttämättä ole lainkaan huono ajatus..

Täältä manuaalia: http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#local


r


r

[mgronber]

Tuntuu pelaavan ok. Valitettavasti on GTK-versio, mutta no, elämä on..

Itse käytän komentoriviversiota.

Kokeilin myös mitä se tuumii jos muokkaakin molempia päitä: näyttää diffin eikä suostu tekemään mitään vaan skippaa tiedoston: tähän pitänee kiinnittää huomiota (meinaan että tarvii tulla huomatuksi tuollaiset..)

Tätä tarkoitin kun sanoin ajavani skriptin manuaalisesti ja että en edes haluaisi sen toimivan millään muulla tavoin. Jos siinä on automatiikkaa mukana niin virhetilanteiden huomaaminen on automatiikan vastuulla.

SSH:n yli menee nätisti, kysyy tosin salasanan, sen kiertoa pitää tutkaista jotenkin..

Koodia: (man ssh) [Valitse]

The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in.
When the user logs in, the ssh program tells the server which key pair it would like to use
for authentication.  The client proves that it has access to the private key and the server
checks that the corresponding public key is authorized to accept the account.

The user creates his/her key pair by running ssh-keygen(1).  This stores the private key in
~/.ssh/identity (protocol 1), ~/.ssh/id_dsa (protocol 2 DSA), or ~/.ssh/id_rsa (protocol 2
RSA) and stores the public key in ~/.ssh/identity.pub (protocol 1), ~/.ssh/id_dsa.pub (pro-
tocol 2 DSA), or ~/.ssh/id_rsa.pub (protocol 2 RSA) in the user’s home directory.  The user
should then copy the public key to ~/.ssh/authorized_keys in his/her home directory on the
remote machine.  The authorized_keys file corresponds to the conventional ~/.rhosts file,
and has one key per line, though the lines can be very long.  After this, the user can log
in without giving the password.

Eli luot asiakaskoneella (yhteyttä ottava kone) avainparin ilman salasanaa komennolla "ssh-keygen -t dsa" ja sitten lisäät asiakaskoneen ~/.ssh/id_dsa.pub tiedoston sisällön palvelinkoneen tiedostoon ~/.ssh/authorized_keys.

Jos haluat että kaikki koneet pystyvät ottamaan yhteyden toisiinsa suoraan ilman salasanaa niin sitten luot jokaisella koneella oman avainparin ja levität niiden julkiset avaimet toisiin koneisiin.

Helppiä katsellessa näyttäisi että unison osaa jopa pitää varmuuskopioita noista synkkauksista mikä ei välttämättä ole lainkaan huono ajatus..

Ei välttämättä huono ajatus jos sitä ei hoida mitenkään muuten. Itselläni varmuuskopiot otetaan rsync:n avulla päivittäin ja tähän mennessä pitäisi olla likimain jokainen päivä tallessa järjestelmän käyttöönotosta lähtien (154 päivää).

[Risto H. Kurppa]

jep, ok, luulen että olisin suht valmis unisonin käyttöönotolle. Nyt siis olen sitä komentoriviltä noin testimielessä ajellut.

Eli pitäisi saada ajautumaan sekä heti kirjautumisen jälkeen että uloskirjautumisen lopuksi. Ehdotuksia?

Oma ensimmäinen ajatukseni on tipauttaa KDM pois ja laittaa kirjautuminen shelliin ja automaattisesti (mikäs se on, .bashrc tms) ajamaan tuo synkkausskripti ja sen onnistuneen ajon jälkeen startata X. Ja vielä perään toinen ajo samaa skriptiä (jotta uloskirjautumisen jälkeen synkataan taas).

Typerää tässä on hibernaten&suspendin tipahtaminen pois käytöstä ja 'ruma komentorivi' Eli kivahan se olisi synkata vasta työpöydällä jne, mutta toteuttaminen on hieman hankalaa (esim. työpöydän taustakuva ei vaihtune lennosta vaikka uudet tiedot tuotaisiin toiselta koneelta..). Käsin en myöskään haluaisi synkkausta käynnistellä, vaan automaattikäynnistys ja puuttuminen vasta vikatilanteissa.

Tässä jotain linkkivinkkejä KDM:n kanssa leikkimiseen, tutkin myöhemmin:
http://wiki.linuxfromscratch.org/hints/browser/trunk/execute-session-scripts-using-kdm.txt
http://linux.bononline.nl/linux/sessionscripts/ (näyttää itseasiassa aika hyvältä!)



r

[Risto H. Kurppa]

No ei noista hirviästi iloa ollut kuitenkaan.

Tällä hetkellä ehkäpä ajattelisin tipauttavani usplashin pois peittämästä näkymää ja pistäväni nuo synkkaskriptit rc2:n loppupuolelle, ennen KDM:ää roottina ajettavaksi ja luon sopivan ssh-tunnarin serverille jolla synkkaus hoidetaan - ja koko home, tai siis molemman käyttäjän datat kerralla luultavasti...

Starttaillaanko noita rc2-skriptejä muuten rinnakkain vai odottaako edellinen aina seuraavaa tai saako tämmöisen pakotettua jotenkin?


r

[Risto H. Kurppa]

Jaa, juu, eiköhän tästä jotain saada kokoon..

Pistän rc2.d:n symlinkin skriptiini, kopioin pohjan cronista (saa start/stop/restart jne -parametrit suoraan) ja muoksin sinne haluamani jutut.

Vielä pitää yrittää selvittää sitä rinnakkaisjupinaa, mutta arvaisin että se tosiaan riippuu sen oman skriptini sisällöstä, notta jäädäänkö suorituksia odottelemaan.. Triviaalihan on $:n käyttö lopuksi jottei odoteltaisi, mutta kokeillaan...

r

[Risto H. Kurppa]

Jaah, KDM starttaakin jo K01:nä eli ihan runlevel kakkosen alussa. No, pitää tunkea tuo synkka vielä ennen sitä ja siivota usplash pois.

Moinen tuli mieleen että onko kenelläkään käsitystä miten tuo unison käsittelee oikeudet: eli pitääkö kaikilla koneilla, joihin synkkaillaan, olla käyttäjät 'samassa järjestyksessä' eli samoilla uid:illä jotta homma pelaa? Mitä tapahtuu jos käyttäjän kotikansion uid:t muuttuukin yhtäkkiä vaikka 1000-> 1001 jonkun synkan yhteydessä, arvatenkin pieleen menee?

No ei mahdoton ajatus, tarkoitus onkin asentaa ehkä kaikki kolme konetta uusiksi (kahteen 32->64bit)..

r

[mgronber]

Moinen tuli mieleen että onko kenelläkään käsitystä miten tuo unison käsittelee oikeudet: eli pitääkö kaikilla koneilla, joihin synkkaillaan, olla käyttäjät 'samassa järjestyksessä' eli samoilla uid:illä jotta homma pelaa?

Koodia: (man unison) [Valitse]

$ man unison
[...]
       -numericids
              don’t map uid/gid values by user/group names
[...]

Tuosta päätellen oletuksena siirretään käyttäjien ja ryhmien nimillä ja tuon parametrin kanssa siirrossa käytetään id-arvoja.