correct directorys for www.ltsp.org (for swap)
Hello, im have debianized www.ltsp.org. the root-filesystem will now point to /usr/share/ltsp/ and mounted read-only by the clients Now i need to have a swapfile folder where all the NFS_Swap files for the clints can be. Please tell me wich directory would be fine. I thinking about /var/cache/ltsp because refering to the FHS 5.2 /var/cache : Application cache data Package specific cache data ..Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. (if you dont delete when the client will be up no problem) Daniel Please don't CC me, i read the list -- Retrieve my key from: www.keyserver.de blackhole.pca.dfn.de horowitz.surfnet.nl keyID 7B196671 or send email with subject "fetch key" signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: correct directorys for www.ltsp.org (for swap)
Hello! [Sun, 28 Sep 2003] Daniel Josua Priem wrote: > Hello, > im have debianized www.ltsp.org. Have you looked at http://termserv.berlios.de/debian/dists/stable/non-free/binary-i386/ ? > the root-filesystem will now point to /usr/share/ltsp/ and mounted > read-only by the clients /usr/share is for architecture independent data. As the root fs for the clients can be regenerated, that should go into /var/lib/ltsp/. > Now i need to have a swapfile folder where all the NFS_Swap files for > the clints can be. Please tell me wich directory would be fine. > I thinking about /var/cache/ltsp because refering to the FHS > > 5.2 /var/cache : Application cache data > > Package specific cache data > ..Such data is locally generated as a result of time-consuming I/O > or calculation. The application must be able to regenerate or restore > the data. > > (if you dont delete when the client will be up no problem) I guess you are implying the question whether this is the right place or not... ;-] It seems to me. Robert. -- Despite the best efforts of a quantum bigfoot drive (yes I know everyone told me they suck, now I know they were right) 2.1.109ac1 is now available -- Alan Cox announcing Linux 2.1.109ac1 pgprRnmNZ6RAb.pgp Description: PGP signature
Re: correct directorys for www.ltsp.org (for swap)
On Sun, Sep 28, 2003 at 09:54:03AM +0200, Robert Jordens wrote: | > the root-filesystem will now point to /usr/share/ltsp/ and mounted | > read-only by the clients | | /usr/share is for architecture independent data. As the root fs for the | clients can be regenerated, that should go into | /var/lib/ltsp/. No, in LTSP the one root filesystem image is static data shared between all clients of a given arch and can't be regenerated except by reinstalling LTSP: thus it belongs in /usr not /var. Also it is "architecture independent" from a Debian packaging perspective as the architecture of the clients need not match the architecture of the file server; it would make sense to have an i386 LTSP root fs stored on a Sparc NFS server, for instance. Thus /usr/share is the correct location. | > Now i need to have a swapfile folder where all the NFS_Swap files for | > the clints can be. Please tell me wich directory would be fine. | > I thinking about /var/cache/ltsp because refering to the FHS [...] | | I guess you are implying the question whether this is the right place or | not... ;-] It seems to me. Possibly /var/tmp or /var/lib would also be an option? Not sure which of the three is best, though. Cameron.
Re: correct directorys for www.ltsp.org (for swap)
Hello! [Sun, 28 Sep 2003] Cameron Patrick wrote: > | /usr/share is for architecture independent data. As the root fs for the > | clients can be regenerated, that should go into > | /var/lib/ltsp/. > > No, in LTSP the one root filesystem image is static data shared between > all clients of a given arch and can't be regenerated except by > reinstalling LTSP: thus it belongs in /usr not /var. Also it is Oh yes. You are right. I thought the root tree was still being gererated from the host server's tree, but those times seem to have passed. But this is strange. Why does lts-core include it's own version of busybox and X and other packages? Why not use the Debian packages and unpack them into the lts-root? What about security fixes as the recent one in xfree86? Those don't get onto the lts-clients until a new lts is uploaded. Robert. -- I asked the engineer who designed the communication terminal's keyboards why these were not manufactured in a central facility, in view of the small number needed [1 per month] in his factory. He explained that this would be contrary to the political concept of local self-sufficiency. Therefore, each factory needing keyboards, no matter how few, manufactures them completely, even molding the keypads. -- Isaac Auerbach, IEEE "Computer", Nov. 1979 pgp0S3AkADwOZ.pgp Description: PGP signature
Re: correct directorys for www.ltsp.org (for swap)
Am Son, 2003-09-28 um 10.55 schrieb Robert Jordens: > Hello! > > [Sun, 28 Sep 2003] Cameron Patrick wrote: > > | /usr/share is for architecture independent data. As the root fs for the > > | clients can be regenerated, that should go into > > | /var/lib/ltsp/. > > > > No, in LTSP the one root filesystem image is static data shared between > > all clients of a given arch and can't be regenerated except by > > reinstalling LTSP: thus it belongs in /usr not /var. Also it is > > Oh yes. You are right. I thought the root tree was still being gererated > from the host server's tree, but those times seem to have passed. > > But this is strange. Why does lts-core include it's own version of > busybox and X and other packages? Why not use the Debian packages and > unpack them into the lts-root? What about security fixes as the recent > one in xfree86? Those don't get onto the lts-clients until a new lts is > uploaded. All this things will be fixed by me. i'm actuallay only use the directory tree and some specials like get_ltscfg all the other binarys are copied by me from hand so on my ltsp package you run only (excluding the lstconfs) "debian-binarys" ( i actually write a script wich will do that) to the right place. long before i run dpkg-buildpackage. so if lets say busybox get e security hole in this moment when i get an update from sec.d.oi build a new package with the fixed holes. Daniel > > Robert. > > -- > I asked the engineer who designed the communication terminal's keyboards > why these were not manufactured in a central facility, in view of the > small number needed [1 per month] in his factory. He explained that this > would be contrary to the political concept of local self-sufficiency. > Therefore, each factory needing keyboards, no matter how few, manufactures > them completely, even molding the keypads. > -- Isaac Auerbach, IEEE "Computer", Nov. 1979 -- Retrieve my key from: www.keyserver.de blackhole.pca.dfn.de horowitz.surfnet.nl keyID 7B196671 or send email with subject "fetch key" signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: correct directorys for www.ltsp.org (for swap)
So as total summary: rootfs will be /usr/share/ltsp/where means CLIENT arch rootswap will be /var/cache/ltspbecause refering to FHS "/var/cache : Application _cache_ dataset different disk and backup policies.." If anybody willing to tell other directorys. Tell but please say why. It's a "nice" work for me to rebuild over 30 packages due to dirchanges. Daniel -- Retrieve my key from: www.keyserver.de blackhole.pca.dfn.de horowitz.surfnet.nl keyID 7B196671 or send email with subject "fetch key" signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: correct directorys for www.ltsp.org (for swap)
On Sun, Sep 28, 2003 at 10:55:56AM +0200, Robert Jordens wrote: > Hello! > [Sun, 28 Sep 2003] Cameron Patrick wrote: > > | /usr/share is for architecture independent data. As the root fs for the > > | clients can be regenerated, that should go into > > | /var/lib/ltsp/. > > No, in LTSP the one root filesystem image is static data shared between > > all clients of a given arch and can't be regenerated except by > > reinstalling LTSP: thus it belongs in /usr not /var. Also it is > Oh yes. You are right. I thought the root tree was still being gererated > from the host server's tree, but those times seem to have passed. > But this is strange. Why does lts-core include it's own version of > busybox and X and other packages? Why not use the Debian packages and > unpack them into the lts-root? What about security fixes as the recent > one in xfree86? Those don't get onto the lts-clients until a new lts is > uploaded. FWIW, last time I tried I found that it was rather difficult to run debootstrap from within a package postinst script... at least with debconf using an interactive frontend. :) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: correct directorys for www.ltsp.org (for swap)
Hello! [Sun, 28 Sep 2003] Steve Langasek wrote: > > But this is strange. Why does lts-core include it's own version of > > busybox and X and other packages? Why not use the Debian packages and > > unpack them into the lts-root? What about security fixes as the recent > > one in xfree86? Those don't get onto the lts-clients until a new lts is > > uploaded. > > FWIW, last time I tried I found that it was rather difficult to run > debootstrap from within a package postinst script... at least with > debconf using an interactive frontend. :) Yes. debootstrap in postinst is not a good idea. It is likely to fail and takes tool long. But a tool on top of debootstrap and the ltsp generation scripts should allow that kind of updating and would not require new ltsp packages for every security advisory. Robert. -- Kiss your keyboard goodbye! pgpteK7enaE3C.pgp Description: PGP signature
Re: correct directorys for www.ltsp.org (for swap)
Am Son, 2003-09-28 um 17.24 schrieb Robert Jordens: > Hello! > > [Sun, 28 Sep 2003] Steve Langasek wrote: > > > But this is strange. Why does lts-core include it's own version of > > > busybox and X and other packages? Why not use the Debian packages and > > > unpack them into the lts-root? What about security fixes as the recent > > > one in xfree86? Those don't get onto the lts-clients until a new lts is > > > uploaded. > > > > FWIW, last time I tried I found that it was rather difficult to run > > debootstrap from within a package postinst script... at least with > > debconf using an interactive frontend. :) > > Yes. debootstrap in postinst is not a good idea. It is likely to fail > and takes tool long. and i get a lot of uneeded files in the filesystem But a tool on top of debootstrap and the ltsp do you think something like this ltsp-core has something similar(or debootstrap with --options) to debootstrap lets say build_rootfs.sh clientarch=i386/mips/ppc xservers=all/svga/vga16 from=f.d.o saveconf=/etc/ltsp/rootfs.conf on secupdates we update ltsp-core in postinst.ex have something like build_rootfs.sh readconf /etc/ltsp/rootfs.conf --update rootfs wich then will do nothing other then looking for newer debs download them unpack them to the rootfs. Please critic me if i'm wrong. i need to learn and figure out this. Daniel > generation scripts should allow that kind of updating and would not > require new ltsp packages for every security advisory. > > Robert. > > -- > Kiss your keyboard goodbye! -- Retrieve my key from: www.keyserver.de blackhole.pca.dfn.de horowitz.surfnet.nl keyID 7B196671 or send email with subject "fetch key" signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: correct directorys for www.ltsp.org (for swap)
Hello! [Sun, 28 Sep 2003] Daniel J. Priem wrote: > build_rootfs.sh clientarch=i386/mips/ppc xservers=all/svga/vga16 > from=f.d.o saveconf=/etc/ltsp/rootfs.conf > > on secupdates we update ltsp-core This seems unnecessary and won't work as desired. If ltsp is in stable you cannot ask for a security update of ltsp-core everytime a security advisory for busybox or xfree86 happens. So people will have to update their rootfs manually anyway. > in postinst.ex have something like The local admin should realize that his reaction to a security advisory should not only be "apt-get update && apt-get upgrade" but also: > build_rootfs.sh readconf /etc/ltsp/rootfs.conf --update rootfs That should be sufficient. That should be put into README.Debian. > wich then will do nothing other then looking for newer debs download > them unpack them to the rootfs. Nice. Well done. Are you in contact with the skolelinux people? LTSP is something really useful for a school (it was for mine). Robert. pgp4hw4rAJ91t.pgp Description: PGP signature
Re: correct directorys for www.ltsp.org (for swap)
On Sun, Sep 28, 2003 at 05:59:15PM +0200, Robert Jordens wrote: > This seems unnecessary and won't work as desired. If ltsp is in stable > you cannot ask for a security update of ltsp-core everytime a security > advisory for busybox or xfree86 happens. Why not? I mean I do agree that it is not the nices solution, but I dont see a reason for not fixing security problems. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: correct directorys for www.ltsp.org (for swap)
Hello! [Sun, 28 Sep 2003] Bernd Eckenfels wrote: > On Sun, Sep 28, 2003 at 05:59:15PM +0200, Robert Jordens wrote: > > This seems unnecessary and won't work as desired. If ltsp is in stable > > you cannot ask for a security update of ltsp-core everytime a security > > advisory for busybox or xfree86 happens. > > Why not? I mean I do agree that it is not the nices solution, but I dont see > a reason for not fixing security problems. I guess you overread the alternative: choose between new lts-core advisories and a simple build_rootfs.sh readconf /etc/ltsp/rootfs.conf --update rootfs for every advisory. Robert. -- System restarting, wait... pgpKoZBpqFkr4.pgp Description: PGP signature
