Miten spool eri levylle ?

[ajaaskel]

Systeemilevy on täyttymäisillään mutta koneessa on toinen levy jolla on runsaasti vapaata. Missä Ubuntussa on määritetty spoolauslevy eli miten käännän spoolin toimimaan toisella levyllä missä tilaa on vapaana ?

   

[juyli]

Systeemilevy on täyttymäisillään mutta koneessa on toinen levy jolla on runsaasti vapaata. Missä Ubuntussa on määritetty spoolauslevy eli miten käännän spoolin toimimaan toisella levyllä missä tilaa on vapaana ? 

Varsin kätevästi (lähes) minkä tahansa hakemiston, voi linkata (ln -s ) mille tahansa jo liitetylle levyosiolle (tai sen hakemistoon).
Tarvittaessahan voi toki /etc/fstab:ia käyttää.

[ajaaskel]

Varsin kätevästi (lähes) minkä tahansa hakemiston, voi linkata (ln -s )....

Voisitko antaa malliratkaisun tähän yksittäiseen ongelmaan ? Kyseessä siis printtauksen ohjaus, tuo spool menee olettaisin ---> /var/spool/cups -hakemistoon oletuksena ja käytettävissä on tyhjä levy joka näkyy montattuna ---> /media/40G.


Edit:  Kokeilin tuota "ln -s" -ideaa, pieniä ongelmia seuraa kun käynnistää taas cupsd: n:

E [31/Jan/2011:17:26:02 +0200] Unable to change ownership of "/var/spool/cups/tmp" - Permission denied
E [31/Jan/2011:17:26:02 +0200] Unable to open directory "/var/spool/cups/tmp" - Permission denied
 
(vaikka muutin ownerit rootille tuolla kohteessa). Tuossa näkyy se softlinkki uuteen paikkaan:

/var/spool# ls -la
yhteensä 36
drwxr-xr-x  9 root root 4096 2011-01-31 17:09 .
drwxr-xr-x 14 root root 4096 2010-10-07 19:12 ..
drwxr-xr-x  2 root root 4096 2010-11-07 21:33 anacron
drwxr-xr-x  5 root root 4096 2010-10-07 19:02 cron
lrwxrwxrwx  1 root root   15 2011-01-31 17:09 cups -> /media/40G/cups
lrwxrwxrwx  1 root root    7 2010-11-07 21:22 mail -> ../mail
drwx--x---  3 root lp   4096 2011-01-31 16:36 oldcups
drwxr-xr-x  3 root root 4096 2010-10-07 19:01 openoffice
drwxr-xr-x  2 root root 4096 2010-09-24 15:50 plymouth
drwxr-xr-x 18 root root 4096 2011-01-21 20:32 postfix
drwxrwxrwt  2 root root 4096 2010-10-06 01:26 samba

Edit2: Jostain syystä en saa muutettua tuota "cups" linkkiä "root:lp" kuten se on alkuaan (hakemistona) ollut.

[Vika/fiba]

drwx--x---  3 root lp   4096 2011-01-31 16:36 oldcups

Jos tämä on alkuperäinen cups-hakemisto, pitäisi uudelle, siis /media/40G/cups-hakemistolle antaa samat oikeudet lp-ryhmälle.
Minä linkkasin joskus (symbolisesti) koko homen toiselle kovolle ja hyvin toimi, mutta silloinkin piti säätää kohdekansion oikeuksia.

Ja pöh! tmp-hakemiston oikeuksistahan tässä oli kyse. Minulla siellä lukee drwxrwx--T 3 root lp
eli lp-ryhmällä on niitä oikeuksia, tuo T taitaa vastustaa.

[ajaaskel]

Tuo kohde "tmp" on tällä tavalla:

drwxrwxrwx 2 root lp   4096 2011-01-31 17:15 tmp

E [31/Jan/2011:18:52:49 +0200] Unable to change permissions of "/var/spool/cups/tmp" - Permission denied
E [31/Jan/2011:18:52:49 +0200] Unable to open directory "/var/spool/cups/tmp" - Permission denied

Lieneekö tuolla sticky bitin (T) puuttumisella tässä merkitystä ?  Toiseksi, tuolla linkissä myös lukee sitkeästi "root:root", ei anna muuttaa sitä, chmod ei anna mitään virhettä mutta ei muutu "root:lp" millään ilveellä, kummallista ?

lrwxrwxrwx  1 root root   15 2011-01-31 17:09 cups -> /media/40G/cups

[Vika/fiba]

Empä ymmärrä missä vika, mutta koska olen purkkaviritysten harrastaja, kokeilisin oikeuksien muuttamista gksudo nautiluksella jos komentorivi ei tehoa. Ja tietysti voisi koittaa ylempää eli sen spool-kansion linkittämistä. (Voi ehkä syntyä lisää sotkua)
Tekeekö muuten kirjoitin sen temppikansion; jos poistais kokonaan tmp:n /media/40G/cupsista

[ajaaskel]

Tulee enää vain yksi virhe, nyt on "sticky bit": kin samalla tavalla kohteen tmp: llä (eli tuo iso T, chmod 1770):

E [31/Jan/2011:19:39:44 +0200] Unable to open directory "/var/spool/cups/tmp" - Permission denied

drwxrwx--T 2 root lp   4096 2011-01-31 17:15 tmp


Printatessa näyttää näin (en muuta odottanutkaan):

[ylläpito on poistanut liitteen]

[ajaaskel]

Tekeekö muuten kirjoitin sen temppikansion; jos poistais kokonaan tmp:n /media/40G/cupsista

Kokeilin hävittää koko "cups" hakemiston, tein uudestaan + chmod 1770 +chown root:lp, jätin "tmp" hakemiston tekemättä ja cupsd käyntiin, printtausyritys saa aikaan nyt:

E [31/Jan/2011:20:04:54 +0200] Unable to create request file /var/spool/cups/00000000: Permission denied
 
Vanhat tutut ilmestyvät myös:

E [31/Jan/2011:20:09:56 +0200] Unable to create directory "/var/spool/cups/tmp" - Permission denied
E [31/Jan/2011:20:09:56 +0200] Unable to open directory "/var/spool/cups/tmp" - No such file or directory

[juyli]

Voisitko antaa malliratkaisun tähän yksittäiseen ongelmaan ? Kyseessä siis printtauksen ohjaus, tuo spool menee olettaisin ---> /var/spool/cups -hakemistoon oletuksena ja käytettävissä on tyhjä levy joka näkyy montattuna ---> /media/40G.

Luulen, että sinulle on sattunut hakemiston kopioimisessa/siirtämisessä virhe. Tar olisi säilyttänyt hakemistojen omistajat ja oikeudet oikein jopa sticky T bittiä myöten.

Edit2: Jostain syystä en saa muutettua tuota "cups" linkkiä "root:lp" kuten se on alkuaan (hakemistona) ollut.

Eikö chgrp toimi? Tosin pitäisi tuon onnistua myös chown komennolla.

Korjaus onnistunee, jos tuon oldcups:in kopioit tar:lla tuolle väljemmälle levylle. Eikös nuo oikeudet ole oikein tuolla varmuuskopiolla oldcups? cp on nätti ohjelma, mutta hyvin tarkkana pitää olla sen eri parametrien kanssa.

[ajaaskel]

Apparmor  ?  Näyttää olevan runsaasti näitä "apparmor kieltänyt" -viestejä logissa: 

apparmor="DENIED" operation="open" parent=11511 profile="/usr/sbin/cupsd" name="/media/40G/cups/tmp/" pid=11512

[ajaaskel]

Annoin "sudo service cups restart" pari kertaa ja tässä on "dmesg | tail":

[249745.193734] type=1400 audit(1296557394.285:92): apparmor="STATUS" operation="profile_replace" name="/usr/lib/cups/backend/cups-pdf" pid=12250 comm="apparmor_parser"
[249745.194574] type=1400 audit(1296557394.285:93): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/cupsd" pid=12250 comm="apparmor_parser"
[249745.416430] type=1400 audit(1296557394.509:94): apparmor="DENIED" operation="open" parent=12255 profile="/usr/sbin/cupsd" name="/media/40G/cups/tmp/" pid=12256 comm="cupsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[249807.574629] type=1400 audit(1296557456.665:95): apparmor="STATUS" operation="profile_replace" name="/usr/lib/cups/backend/cups-pdf" pid=12274 comm="apparmor_parser"
[249807.575500] type=1400 audit(1296557456.665:96): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/cupsd" pid=12274 comm="apparmor_parser"
[249807.631473] type=1400 audit(1296557456.721:97): apparmor="DENIED" operation="open" parent=12280 profile="/usr/sbin/cupsd" name="/media/40G/cups/tmp/" pid=12281 comm="cupsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Ylläoleva login osuus saattaa olla seuraus eikä syy.  Hämärää on edelleen miksi "cupsd" herjaa. Jotain on varmaan edelleen jäänyt huomaamatta mutta onko joku saanut tämän toimimaan Ubuntussa eli osaako "cupsd" toimia softlinkin kautta ?   Asia ei ole mitenkään kriittinen mutta mielenkiintoinen ja hyödyllinen vastaisuudessa jos tuon saa helposti toimimaan.   Tuohon voisi olla parempikin tapa kuin yrittää softlinkillä veivata print spool hakemistoa levyltä toiselle, en tiedä voisiko sen  määrittää jotenkin (miten ?) suoraan "cupsd": lle.   Tiedän että "ennen vanhaan" tuon pystyi määrittämään /etc/printcap  -tiedostoon mutta nykyään tuo on automaattisesti generoitu...

Ellei tuo ratkea niin voin tietysti kiertotienä vaihtaa levyn isompaan ja säätää osiot sellaisiksi että riittää.

[SuperOscar]

Eihän linkin omistajaa, ryhmää tai oikeuksia voi muuttaa. Linkin kohteen voi. Tässä esimerkki:

Koodia: [Valitse]

tn@bahtin [~/Tilap/test]$ dir
yhteensä 0
tn@bahtin [~/Tilap/test]$ touch foo
tn@bahtin [~/Tilap/test]$ dir
yhteensä 0
-rw------- 1 tn tn 0 2011-02-01 13:30 foo
tn@bahtin [~/Tilap/test]$ ln -s foo bar
tn@bahtin [~/Tilap/test]$ dir
yhteensä 0
lrwxrwxrwx 1 tn tn 3 2011-02-01 13:30 bar -> foo
-rw------- 1 tn tn 0 2011-02-01 13:30 foo
tn@bahtin [~/Tilap/test]$ chown root:root bar
chown: vaihdettaessa tiedoston ”bar” omistajuutta: Toiminto ei ole sallittu
tn@bahtin [~/Tilap/test]$ dir
yhteensä 0
lrwxrwxrwx 1 tn tn 3 2011-02-01 13:30 bar -> foo
-rw------- 1 tn tn 0 2011-02-01 13:30 foo
Yritin joskus siirtää symbolisella linkillä koko /var-puun toiselle levylle, mutta siitä seurasi niin paha jumi, että tarvittiin livelevyä apuun. En tiedä, mutta ehkä jotkin systeemihakemistot voi siirtää muualle vain liittämällä ne /etc/fstabissa, ei symbolista linkkiä käyttäen (?).

[ajaaskel]

Eihän linkin omistajaa, ryhmää tai oikeuksia voi muuttaa.

Joo, puskettuani päätä seinään "chown": in kanssa hetken tajusin että kaikki toimenpiteet kohdistuvat linkin kohteeseen eikä itse linkkiin (sen "inode").     Samalla heräsikin seurauskysymys:  Mikä merkitys ja käytännön vaikutus on linkin omilla atribuuteilla ?    Jos siellä on esimerkiksi näin:

lrwxrwxrwx  1 root root   15 2011-02-01 01:14 linkcups -> /media/40G/cups

niin vaikuttaako tuo "linkcups" -softlinkin oman inoden "root:root" johonkin ?  Sitähän ei voinut "tietysti" muuttaa kun muutos kohdistuu aina linkin kohteeseen ?  Hyvä dokumentti jossain tuosta ?
 

Yritin joskus siirtää symbolisella linkillä koko /var-puun toiselle levylle

MuTu:  Lieneekö niin että jotkut ohjelmat vaativat alleen "oikean" hakemiston tai levyn eli eivät toimi linkillä --- vai onko tähän mahdollista perustetta  ?

[juyli]

Hyvä dokumentti jossain tuosta ?

man ln ja sivuilla vihje:

Koodia: [Valitse]

info coreutils 'ln invocation'

Yritin joskus siirtää symbolisella linkillä koko /var-puun toiselle levylle

MuTu:  Lieneekö niin että jotkut ohjelmat vaativat alleen "oikean" hakemiston tai levyn eli eivät toimi linkillä --- vai onko tähän mahdollista perustetta  ?

Tuo minuakin kyllä ihmetyttää, mutta koska muistin joitakin ongelmiakin syntyneen linkityksistä joissakin tilanteissa, kirjoitin jo ensimmäisessä viestissäni varolausekkeen (lähes)
Tuon cups -hakemiston siirtohan oli vähintäänkin ongelmallinen tuon ryhmän lp -oikeuksista.
En nyt viitsi itse kokeilla, mutta koko spool:in omistus olisi root ja ryhmä root, joten linkin omistajuus ja ryhmä olisivat oikein koko spool:in siirtämiseksi (?). (Ei kannata kokeilla kotona).
Toki myös tuo apparmor tekee oman mutkansa matkaan - kuten vaikkapa SElinux.
Usein järjestelmätasoisia muutoksia tehdessä, kannattaa käyttää Recovery Mode, LiveCD tai muita RescueCD -systeemejä, ettei käynnissäolevat ohjelmat häiritse kopionti- tai siirto-operaatioita. Tietysti myös kaikki aiheeseen liittyvät palvelut kannattaa sulkea.
Vielä minua jää hieman vaivaamaan, miten olet liittänyt tuon kovalevyosion, jolle cups-hakemiston tallensit.

Lisäys: Coreutils doc:it löytyvät /var/usr/share/doc/coreutils-8.5
/var/usr/share/doc/policycoreutils-2.0.83 (tuo coreutils:in versionumero voi olla toinen)

[ajaaskel]

Linkin itsensä (inode) "root:root":
Tuoltahan se löytyi (info coreutils...) , hätäinen käännös suomeksi: "Itse linkin owner: lla ja group: lla ei ole merkitystä linkin kautta tapahtuvan käytön kannalta mutta ne voivat vaikuttaa linkin poistamiseen jos linkki sijaitsee hakemistossa jolle on laitettu restricted deletion bit päälle".

"40G" -nimisen levyn monttaus:
Se oli automontattu jo tuonne --> /media/40G kun aloin kokeilla tuota spoolin viritystä toiselle levylle softlinkin läpi.  Sammutin aina "cupsd": n ennen muutoksia ja käynnistin lopuksi uudestaan.