Hi all, looking at fhs 2.3 and thinking about what needs to be done for fc3 - just a few things that people could get working on early:
/srv - user data for services not owned by a single specific user there ie: /srv/www /srv/vsftpd /srv/postgresql ? /srv/mysql ? /srv/jabberd ? /srv/bittorrent ?
/media - all the removable media and silliness there.
Thoughts on looking through the daemons and seeing what needs to be fixed up to meet this?
-sv
On Tue, Mar 30, 2004 at 05:57:21PM -0500, seth vidal wrote:
/srv - user data for services not owned by a single specific user there ie: /srv/www /srv/vsftpd /srv/postgresql ? /srv/mysql ? /srv/jabberd ? /srv/bittorrent ?
/media - all the removable media and silliness there.
If I remember right, Red Hat people hate both of these. For whatever that's worth. :)
On Tue, 2004-03-30 at 14:57, seth vidal wrote:
Hi all, looking at fhs 2.3 and thinking about what needs to be done for fc3 - just a few things that people could get working on early:
/srv - user data for services not owned by a single specific user there ie: /srv/www /srv/vsftpd /srv/postgresql ? /srv/mysql ? /srv/jabberd ? /srv/bittorrent ?
So . . . remind me how this is different (fundamentally) from /var ?
/media - all the removable media and silliness there.
And why isn't /mnt adequate for removable media?
Thoughts on looking through the daemons and seeing what needs to be fixed up to meet this?
-sv
On Tue, Mar 30, 2004 at 03:15:57PM -0800, Shahms King wrote:
/srv - user data for services not owned by a single specific user there ie:
So . . . remind me how this is different (fundamentally) from /var ?
/var is variable transient data. Users don't edit files there; programs do. It's spools and caches and logs.
/srv may contain a mix of user data and program data, including executable scripts (definitely a no-no in /var!). And, backup strategies for these filesystems is likely to differ from those for /var.
/home/www was a problem, but /var/www is also very very not right.
/media - all the removable media and silliness there.
And why isn't /mnt adequate for removable media?
I thknk this one is silly. Historically, some people are accustomed to using /mnt as a temporary mount point. Therefore, having subdirectores that might be in use would be Terrible.
On Tue, 2004-03-30 at 18:07 -0500, Matthew Miller wrote:
On Tue, Mar 30, 2004 at 05:57:21PM -0500, seth vidal wrote:
/srv - user data for services not owned by a single specific user there ie: /srv/www /srv/vsftpd /srv/postgresql ? /srv/mysql ? /srv/jabberd ? /srv/bittorrent ?
/media - all the removable media and silliness there.
If I remember right, Red Hat people hate both of these. For whatever that's worth. :)
I talked to bill nottingham about it - he didn't seem opposed to /srv but a bit annoyed by /media
I don't think it matters fhs compliance is a must, imo.
-sv
So . . . remind me how this is different (fundamentally) from /var ?
/media - all the removable media and silliness there.
And why isn't /mnt adequate for removable media?
www.pathname.com/fhs/
and here is the list of changes and the bugs where these were discussed.
http://www.pathname.com/fhs/announce-2.3.html
I don't think talking about whether or not we like them is useful here. It is the fhs and fedora core should be compliant with it.
-sv
On Tue, 2004-03-30 at 19:04, seth vidal wrote:
I don't think talking about whether or not we like them is useful here. It is the fhs and fedora core should be compliant with it.
There are plenty of standards out there that are just silly, so compliance for the sake of compliance is probably not the best approach.
Note: I'm not arguing one way or another on this one, just saying that using the argument of "it's a standard" is somewhat weak.
Jeremy
On Tue, 2004-03-30 at 19:14 -0500, Jeremy Katz wrote:
On Tue, 2004-03-30 at 19:04, seth vidal wrote:
I don't think talking about whether or not we like them is useful here. It is the fhs and fedora core should be compliant with it.
There are plenty of standards out there that are just silly, so compliance for the sake of compliance is probably not the best approach.
Note: I'm not arguing one way or another on this one, just saying that using the argument of "it's a standard" is somewhat weak.
How about fhs compliance is something that other distros will have and therefore fedora core should have it too.
Are there other standards out their for the file system hierarchy OTHER than the fhs that fedora or red hat intends to follow? Why is there all this resistance to this?
-sv
seth vidal (skvidal@phy.duke.edu) said:
I talked to bill nottingham about it - he didn't seem opposed to /srv but a bit annoyed by /media
I don't think it matters fhs compliance is a must, imo.
/srv - well, there's no real *other* good place for this stuff, so, go for it.
/media, though, as a standard, is *completely* wrongheaded. Standardizing device names and mountpoints, when they should be left up to sysadmin discretion. Moreover, it doesn't even completely standardize them; there's holes in the naming. And, in any case, all of this information should be exposed to user space via names created by udev, and by a library interface such as HAL; not by a standard that's always going to be playing catchup with new device types.
Bill
On Tue, 30 Mar 2004, seth vidal wrote:
On Tue, 2004-03-30 at 19:14 -0500, Jeremy Katz wrote:
On Tue, 2004-03-30 at 19:04, seth vidal wrote:
I don't think talking about whether or not we like them is useful here. It is the fhs and fedora core should be compliant with it.
There are plenty of standards out there that are just silly, so compliance for the sake of compliance is probably not the best approach.
How about fhs compliance is something that other distros will have and therefore fedora core should have it too.
We should aim for LSB N compliance. If the LSB N does specify FHS X.Y compliance then that is what it takes to be LSB N compliant.
I do hope the LSB team specifies FHS versions as it seems FHS is going to make life harder instead of easier with each new version.
Hugo.
Le mar, 30/03/2004 à 15:15 -0800, Shahms King a écrit :
On Tue, 2004-03-30 at 14:57, seth vidal wrote:
Hi all, looking at fhs 2.3 and thinking about what needs to be done for fc3 - just a few things that people could get working on early:
/srv - user data for services not owned by a single specific user there ie: /srv/www /srv/vsftpd /srv/postgresql ? /srv/mysql ? /srv/jabberd ? /srv/bittorrent ?
So . . . remind me how this is different (fundamentally) from /var ?
Well, speaking as a sysadmin here the size and integrity constraints of /srv are very different from /var. Most of the stuff listed here ends up in different partitions than /var usually, since your typical /var is rarely sized to host the 50 GiB ftp server people might want to install a year from now.
Cheers,
On Wed, 2004-03-31 at 01:15, Shahms King wrote:
/media - all the removable media and silliness there.
And why isn't /mnt adequate for removable media?
I don't think /mnt has anything wrong with it, but FHS specifies that /media is a better name for a removable device and indeed, /media is what SuSE uses.
On Wed, 2004-03-31 at 09:03, Felipe Alfaro Solana wrote:
On Wed, 2004-03-31 at 01:15, Shahms King wrote:
/media - all the removable media and silliness there.
And why isn't /mnt adequate for removable media?
I don't think /mnt has anything wrong with it, but FHS specifies that /media is a better name for a removable device and indeed, /media is what SuSE uses.
/srv requires the sysadmin to allocate space for the services he or she will install, and that is a good reason to separate it from /var
/media instead does not requires that because the contents will be located on removable media, so a symlink to /mnt will solve the differences with FHS
/srv requires the sysadmin to allocate space for the services he or she will install, and that is a good reason to separate it from /var
I do see some reasons to move stuff, but overall the pros of all these changes are not too big. Sysadmins doing wrong sizing for /var can only be "one more small item".
greetings,
Florian La Roche
On Wed, 31 Mar 2004, Florian La Roche wrote:
/srv requires the sysadmin to allocate space for the services he or she will install, and that is a good reason to separate it from /var
I do see some reasons to move stuff, but overall the pros of all these changes are not too big. Sysadmins doing wrong sizing for /var can only be "one more small item".
For me the main reason is * not to mix data with libraries (i.e. mysql databases in /var/lib/mysql/DB_NAME). * idem for logs (/var/log) * idem for websites (/var/www).
Data should be easyly upgradable, so it sould be in a separate path so that it could have its own partition, preserving it in upgrades. Libraries should be updated with the rest of the system.
Now doing this is almost impossible.
Pau
Hi,
A possibly related discussion; we've been wondering if we can make the OS image read-only (mounting it that way, or via selinux).
Then have /tmp and probably /var in RAM (or wiped on boot), and have home directories and server/app data such as web pages to be served on network mounts.
This allows you to maintain the OS image in a central location and the homedirs and server/app data in central locations, and have a single network-wide master copy of all important state.
Any filesystem rearrangement probably impacts this plan (some rearrangement may be needed for this plan).
Havoc
On Wed, 2004-03-31 at 17:38 -0500, Havoc Pennington wrote:
Hi,
A possibly related discussion; we've been wondering if we can make the OS image read-only (mounting it that way, or via selinux).
Then have /tmp and probably /var in RAM (or wiped on boot), and have home directories and server/app data such as web pages to be served on network mounts.
This allows you to maintain the OS image in a central location and the homedirs and server/app data in central locations, and have a single network-wide master copy of all important state.
Any filesystem rearrangement probably impacts this plan (some rearrangement may be needed for this plan).
Havoc
Hello Havoc et al,
I am sure most would disagree, but if Fedora even goes in the direction that would allow this setup to be done easily, you run into several problems of course... the primary one being heterogeneous systems (even if they all are x86, they won't all be the same as far as sse sse2 3dnow 3dnowext, etc.). Also, you have /etc.
However, these can all be overcome using symlinks and other fun things. However, and maybe NFS4 covers this, I don't know. I know codafs and intermezzo do this to different levels. The biggest thing needed (but maybe not always wanted) is a caching file system. One that supports journals locally, acls and all that. Preferably something that does a cached and networked version of ext3. I know codafs doesn't integrate the acls, etc. as well as intermezzo does and wouldn't work as an underpinnings for samba. Intermezzo might, but I don't know. I haven't kept up the last year or two.
Anyway: cached = on disk cache that is only lost when specifically told to be lost or gets bumped due to local disk space being nearly full and is updated automatically from the server.
ACLs and the other extended attributes maybe should be pluggable, depending on the underpinning system (required to be the same on both ends, required to be journaled, etc.)
Sorry if none of this makes sense. I am a bit sleep deprived at the moment.
Trever -- "Having Microsoft give us advice on open standards is like W.C. Fields giving moral advice to the Mormon Tabernacle Choir" -- Scott McNealy, Sun Microsystems Inc.
Once upon a time, Havoc Pennington hp@redhat.com said:
A possibly related discussion; we've been wondering if we can make the OS image read-only (mounting it that way, or via selinux).
I run with /usr read-only already, and if I didn't have users in /etc/passwd I could mount / read-only.
Then have /tmp and probably /var in RAM (or wiped on boot), and have home directories and server/app data such as web pages to be served on network mounts.
/var needs to continue across reboots, as that is where logs are (and not everything can do network logging, nor do you want to log to an NFS mount). I don't see you being able to get away from having some local writable storage.
On 31.03.2004 14:38, Havoc Pennington wrote:
A possibly related discussion; we've been wondering if we can make the OS image read-only (mounting it that way, or via selinux).
Then have /tmp and probably /var in RAM (or wiped on boot), and have home directories and server/app data such as web pages to be served on network mounts.
This allows you to maintain the OS image in a central location and the homedirs and server/app data in central locations, and have a single network-wide master copy of all important state.
Any filesystem rearrangement probably impacts this plan (some rearrangement may be needed for this plan).
We've been doing this with 7.x and 8.0 - a read-olny root-over-nfs partition, /tmp in RAM and read-write /var (each host mounts its own private copy from the server).
We had to do the following things: - /etc/mtab is a symlink to /proc/mounts - Most of /var/lib needs to be moved to the /usr and replaced with symlinks. Especially, /var/lib/rpm, /var/lib/menu, /var/lib/xkb, /var/lib/alternatives. /var/lib/slocate can stay (if you have local partitions and you want to have separate slocate dbs on clients), /var/lib/nfs needs to stay - For /var/log, you'd probably want to change the syslogd.conf to send all logs to the remote server collecting them, instead of logging locally.
On Wed, 2004-03-31 at 15:38, Havoc Pennington wrote:
Hi,
A possibly related discussion; we've been wondering if we can make the OS image read-only (mounting it that way, or via selinux).
Then have /tmp and probably /var in RAM (or wiped on boot), and have home directories and server/app data such as web pages to be served on network mounts.
This allows you to maintain the OS image in a central location and the homedirs and server/app data in central locations, and have a single network-wide master copy of all important state.
Any filesystem rearrangement probably impacts this plan (some rearrangement may be needed for this plan).
You need to talk to the kernel guys to get this workable. The file /etc/mtab will bite you.
Having it be a symlink to /proc/mounts is not sufficient.
The /etc/mtab file is where the mount options are stored. This is something that /proc/mounts doesn't have (other than rw/ro).
Additionally, /proc/mounts has non-meaningful entries like:
rootfs / rootfs rw 0 0 /dev/root / ext3 rw 0 0
It would be nice to get this fixed (incidentally Solaris does this correctly). Go bug Al Viro :)
Dax Kelson Guru Labs
On Wed, Mar 31, 2004 at 05:38:21PM -0500, Havoc Pennington wrote:
Then have /tmp and probably /var in RAM (or wiped on boot), and have home directories and server/app data such as web pages to be served on network mounts.
Once there's in kernel AFS with caching support....
On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote:
On Wed, 2004-03-31 at 01:15, Shahms King wrote:
/media - all the removable media and silliness there.
And why isn't /mnt adequate for removable media?
I don't think /mnt has anything wrong with it, but FHS specifies that /media is a better name for a removable device and indeed, /media is what SuSE uses.
If SuSe decides to jump off the Brooklyn Bridge, are we expected to blindly follow?
On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote:
On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote:
On Wed, 2004-03-31 at 01:15, Shahms King wrote:
/media - all the removable media and silliness there.
And why isn't /mnt adequate for removable media?
I don't think /mnt has anything wrong with it, but FHS specifies that /media is a better name for a removable device and indeed, /media is what SuSE uses.
If SuSe decides to jump off the Brooklyn Bridge, are we expected to blindly follow?
Is SuSE doing something reason not to do it in Fedora/RHEL, etc?
Dan Burcaw became daring and sent these 0.7K bytes,
On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote:
On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote:
On Wed, 2004-03-31 at 01:15, Shahms King wrote:
/media - all the removable media and silliness there.
And why isn't /mnt adequate for removable media?
I don't think /mnt has anything wrong with it, but FHS specifies that /media is a better name for a removable device and indeed, /media is what SuSE uses.
If SuSe decides to jump off the Brooklyn Bridge, are we expected to blindly follow?
Is SuSE doing something reason not to do it in Fedora/RHEL, etc?
Now, in english please?
On Thu, 2004-04-01 at 08:19, Dan Burcaw wrote:
On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote:
On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote:
On Wed, 2004-03-31 at 01:15, Shahms King wrote:
/media - all the removable media and silliness there.
And why isn't /mnt adequate for removable media?
I don't think /mnt has anything wrong with it, but FHS specifies that /media is a better name for a removable device and indeed, /media is what SuSE uses.
If SuSe decides to jump off the Brooklyn Bridge, are we expected to blindly follow?
Is SuSE doing something reason not to do it in Fedora/RHEL, etc?
No, it isn't really, though we have some umm reservations on device naming, file system naming related stuff when it comes from Nuremberg ;-).
/media being used by SuSE is not a reason to do it nor to not do it. So it would be best to leave "SuSE does/doesn't do this that way" aside as an argument.
Nils
Le jeu, 01/04/2004 à 10:14 +0200, Nils Philippsen a écrit :
/media being used by SuSE is not a reason to do it nor to not do it. So it would be best to leave "SuSE does/doesn't do this that way" aside as an argument.
Well, let people in the know argue for /media if they want it. So far no one here seems to have understood what it's supposed to win over /mnt.
/srv OTOH seems to have been well received by a sizable part of the posters - can it go in without being blocked by /media for now ?
Cheers,
On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote:
A possibly related discussion; we've been wondering if we can make the OS image read-only (mounting it that way, or via selinux).
If we do this, apt/yum/up2date/rpm will also need smarts to remount rw when upgrading. Having to do this by hand each time would annoy the hell out of me enough to just make it permanently rw again.
Then have /tmp and probably /var in RAM (or wiped on boot)
Errr, if /var/log disappeared, I'd be very annoyed.
Ditto /var/spool. Imagine a scenario where I had a few hundred emails in /var/spool/mqueue, and for some reason the box locked up. Right now, I can reboot, and they'll still be there, and I can just restart the MTA and everything carries on. With your proposal, that spool is *gone*.
Same is possibly true for other bits of /var too.
This allows you to maintain the OS image in a central location and the homedirs and server/app data in central locations, and have a single network-wide master copy of all important state.
This sounds problematic for laptops. Things like AFS sound like a solution, but from what I've heard about it, I'm not sure I'm ready to trust my /home to it.
Dave
/srv OTOH seems to have been well received by a sizable part of the posters - can it go in without being blocked by /media for now ?
We should further evaluate that. Is LSB-2.0 requireing it? What about compatibility to older versions and upgrade support to current rpms?
Compat symlinks often cause problems, just as well as changing an existing structure. That is often a bigger problem than the advantage of the location of the new directory.
Along the same lines Red Hat satyed conservative by sticking to sendmail instead of changing over to postfix/exim. (I still remember the Linux kongress way back in 1995 where Alan Cox, Linus and a few other said sendmail is not something you should start using on Linux. ;-)
greetings,
Florian La Roche
P.S.: Starting the MTA is not meant to disturbe the discussion. I think it is valuable to understand that any change in behaviour is bad, but Red Hat definitely should look at what point it is important to have enough benefits for e.g. /srv and other new paths.
Ok I have a feeling I know where this sort of configuration would be wanted :) :).. so I figured I should let you know the various problems we have seen with diskless workstations, clusters and other things
On Thu, 2004-04-01 at 03:54, Dave Jones wrote:
On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote:
A possibly related discussion; we've been wondering if we can make the OS image read-only (mounting it that way, or via selinux).
If we do this, apt/yum/up2date/rpm will also need smarts to remount rw when upgrading. Having to do this by hand each time would annoy the hell out of me enough to just make it permanently rw again.
The issues I see are the following:
python items that get recompiled. I have to treat my scripts to ok various .pyc files that seem to change md5sums every now and then.
The following filesystems are heavily mutable and have to be rw /etc mtab configurations and such being pushed out by cfengine, et al. [Rebooting to get the new configuration is not why we switched to Linux :)] /dev permission changes and such
One of the old Unix boxes here had the ability to set / ro (unless single user) and then overmounted a rw /dev /etc with all the entries that were mutable. The only problem we had was when the new sysadmin (me) didnt know that booting single user didnt overmount, and so the changes to /etc/passwd disappeared :).
Things that can be mounted via ramdisk /tmp /var/tmp /var/spool/mqueue/xf/ ## Also /var/spool/MIMEdefang/ if you use it.
Things that have to be available over a reboot/power-outage/etc /var/spool/ /var/log/ [even with central logging it is needed to cross check logs]
Then have /tmp and probably /var in RAM (or wiped on boot)
Errr, if /var/log disappeared, I'd be very annoyed.
Ditto /var/spool. Imagine a scenario where I had a few hundred emails in /var/spool/mqueue, and for some reason the box locked up. Right now, I can reboot, and they'll still be there, and I can just restart the MTA and everything carries on. With your proposal, that spool is *gone*.
Same is possibly true for other bits of /var too.
This allows you to maintain the OS image in a central location and the homedirs and server/app data in central locations, and have a single network-wide master copy of all important state.
This sounds problematic for laptops. Things like AFS sound like a solution, but from what I've heard about it, I'm not sure I'm ready to trust my /home to it.
I doubt very much you would want to run this configuration on a laptop... :).
Dave
Hi,
To be clear, a read-only root would not be the only possible config, it's a specific deployment methodology.
On Thu, 2004-04-01 at 05:54, Dave Jones wrote:
On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote:
A possibly related discussion; we've been wondering if we can make the OS image read-only (mounting it that way, or via selinux).
If we do this, apt/yum/up2date/rpm will also need smarts to remount rw when upgrading. Having to do this by hand each time would annoy the hell out of me enough to just make it permanently rw again.
The whole point is to never run apt/yum/up2date/rpm on individual machines, only on a central image ;-)
Avoid per-system state that can be configured incorrectly, haX0rd, gotten out of sync.
Then have /tmp and probably /var in RAM (or wiped on boot)
Errr, if /var/log disappeared, I'd be very annoyed.
Log to a server for example.
Ditto /var/spool.
IMAP and remote smtp server, or something along those lines. Print servers.
You could have "writable /var" as a possible configuration, too.
This allows you to maintain the OS image in a central location and the homedirs and server/app data in central locations, and have a single network-wide master copy of all important state.
This sounds problematic for laptops. Things like AFS sound like a solution, but from what I've heard about it, I'm not sure I'm ready to trust my /home to it.
If we can't handle laptops this is still useful for server and thin-client-desktop type setups
The way to do laptops though is that the RW master image of homedir is on the laptop, and the laptop keeps a local RO cache of the OS image.
On connection to network, you sync the homedir from laptop to network, and sync the OS image from network to laptop.
Or something, this isn't a mature idea, just a discussion that's come up.
Havoc
On Thu, 2004-04-01 at 12:56, Havoc Pennington wrote:
Hi,
To be clear, a read-only root would not be the only possible config, it's a specific deployment methodology.
On Thu, 2004-04-01 at 05:54, Dave Jones wrote:
On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote:
A possibly related discussion; we've been wondering if we can make the OS image read-only (mounting it that way, or via selinux).
If we do this, apt/yum/up2date/rpm will also need smarts to remount rw when upgrading. Having to do this by hand each time would annoy the hell out of me enough to just make it permanently rw again.
The whole point is to never run apt/yum/up2date/rpm on individual machines, only on a central image ;-)
Ah.. the problem for us has come that we need a ton of diskless systems, but that many have to run different configurations that are out of step from a central image. I had hoped this would be the exception rather than the rule, but it has become more of the rule than anyone expected (and seems to be the rule at other similar organizations.)
The issue comes down to that we need to have 1-2 central servers per network for auditing purposes. The diskless clients may need to run different versions/packages of RHL/Fed/etc off of that diskless server. The current hacks look to be about 5-20 different ways of solving the same problem :).
Avoid per-system state that can be configured incorrectly, haX0rd, gotten out of sync.
One of the things, we have found is that the only way to maintain this when the central box is updated is to kill all the diskless clients, remove their per-system areas (/etc,/dev,/lib,/initrd) and then have them all rebuild themselves a new set of images on reboot. The problem is that 200+ systems doing UDP NFSv2 at nearly the same time kills the linux NFS server.
Then have /tmp and probably /var in RAM (or wiped on boot)
Errr, if /var/log disappeared, I'd be very annoyed.
Log to a server for example.
I am guessing for this configuration that would be the best way. You would need to make sure that for some systems that they could log to multiple log servers at the same time so that they can be independantly audited.
Ditto /var/spool.
IMAP and remote smtp server, or something along those lines. Print servers.
You could have "writable /var" as a possible configuration, too.
You can get away with most of that except when the CxO box dies while an email was being sent and its gone. Murphy seems to strike on this one more than statistically should be possible...
This allows you to maintain the OS image in a central location and the homedirs and server/app data in central locations, and have a single network-wide master copy of all important state.
This sounds problematic for laptops. Things like AFS sound like a solution, but from what I've heard about it, I'm not sure I'm ready to trust my /home to it.
If we can't handle laptops this is still useful for server and thin-client-desktop type setups
The way to do laptops though is that the RW master image of homedir is on the laptop, and the laptop keeps a local RO cache of the OS image.
On connection to network, you sync the homedir from laptop to network, and sync the OS image from network to laptop.
The best way to get this to scale I have seen of doing this is either using 'other filesystems' than NFS or scripts like rsync. The reason is that a couple of the solutions I have seen work with 1-4 laptops but dont scale beyond that. The 'cool' version I saw was a hacked version of rsync that did something like asyncrynous updates. [Whats newer on each system, and according to config rules overwrite usually to the newer version.] The other version was one that would partition the laptop disk into 'mirrors' of itself.
/boot -- 1 I think /1 /2 /home -- 1 I think
boot is set up to boot into say /1 the first time, and then the asyncd updates /2 to whatever the network says it should be. Grub is changed appropriately, and a root message is sent to an applet on the desktop saying updates have been done, please reboot to get to the new configuration. Reboot then starts up by default into /2 and if the user is ok with it via the applet, then /1 can be updated to mirror /2. If not then the user can reboot back into /1 and contact their sysadmin about the problems. [Audits can also be set up to let the central administration which boxes are running old copies in case the user doesnt tell the sysadmins].
/home is backed up in the background to a central server in a similar method.
Or something, this isn't a mature idea, just a discussion that's come up.
Let me know if I can help any..
Havoc
On Thu, 2004-04-01 at 13:54, Dave Jones wrote:
On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote:
A possibly related discussion; we've been wondering if we can make the OS image read-only (mounting it that way, or via selinux).
If we do this, apt/yum/up2date/rpm will also need smarts to remount rw when upgrading. Having to do this by hand each time would annoy the hell out of me enough to just make it permanently rw again.
That's trivial to do in apt with a little Lua-script plugged into right slots - check http://laiskiainen.org/apt/lua/remount/ (yes there are error cases it doesn't handle, but hey, it's just a silly example...)
- Panu -
Stephen Smoogen wrote:
Ah.. the problem for us has come that we need a ton of diskless systems, but that many have to run different configurations that are out of step from a central image. I had hoped this would be the exception rather than the rule, but it has become more of the rule than anyone expected (and seems to be the rule at other similar organizations.)
There's some high level discussion on things related to this here:
.. a high level look at the different large scale configuration systems out there with a view to what's needed going forward to managing Grid systems. There are case studies for a number of existing large scale installations in there ranging from 120 nodes to 1100.
Carwyn
On Thu, 2004-04-01 at 13:28 -0700, Stephen Smoogen wrote:
On Thu, 2004-04-01 at 12:56, Havoc Pennington wrote:
Ditto /var/spool.
IMAP and remote smtp server, or something along those lines. Print servers.
You could have "writable /var" as a possible configuration, too.
You can get away with most of that except when the CxO box dies while an email was being sent and its gone. Murphy seems to strike on this one more than statistically should be possible...
If you're doing direct SMTP, then having a writable /var doesn't help in this case, either. Hopefully your mail client saves to a file (which would be in the home dir) and then does the smtp transaction, removing the file from the home dir after that succeeds.
Jeremy
On Thu, 2004-04-01 at 15:35, Jeremy Katz wrote:
On Thu, 2004-04-01 at 13:28 -0700, Stephen Smoogen wrote:
On Thu, 2004-04-01 at 12:56, Havoc Pennington wrote:
Ditto /var/spool.
IMAP and remote smtp server, or something along those lines. Print servers.
You could have "writable /var" as a possible configuration, too.
You can get away with most of that except when the CxO box dies while an email was being sent and its gone. Murphy seems to strike on this one more than statistically should be possible...
If you're doing direct SMTP, then having a writable /var doesn't help in this case, either. Hopefully your mail client saves to a file (which would be in the home dir) and then does the smtp transaction, removing the file from the home dir after that succeeds.
The boxes were configured to use the local SMTP for some reason (I dont know.. I just had to debug the problem). Thus the mail went from client -> sendmail/var/spool/clientmqueue -> power-outage ooops
The solution was to set up /var/spool/ as a NFS mounted rw. [Getting the 200+ clients to do direct writes and hoping the client did the write thing with a temp file was left to a grad student who is probably still rueing the day he crossed my path.]
Jeremy
On Thu, 2004-04-01 at 15:46 -0700, Stephen Smoogen wrote:
The boxes were configured to use the local SMTP for some reason (I dont know.. I just had to debug the problem). Thus the mail went from client -> sendmail/var/spool/clientmqueue -> power-outage ooops
Heh, that's just sick. How about my statement holding for when the clients are set up correctly? :-) (ie, if you don't use local sendmail and just do smtp, then local /var/spool isn't needed)
So yes, the ability to have it, perfectly reasonable. Having it as the general case, perhaps overkill.
Jeremy
Once upon a time, Jeremy Katz katzj@redhat.com said:
Heh, that's just sick. How about my statement holding for when the clients are set up correctly? :-) (ie, if you don't use local sendmail and just do smtp, then local /var/spool isn't needed)
Way too many programs expect to be able to call /usr/sbin/sendmail to assume everything will use SMTP. And really, that is how it should be; why should every program be required to have an SMTP client built-in?
The nice thing about that is that you are pretty much guaranteed that you can send mail at any time, even if the network is down. Sendmail (or another local mailer) will queue the mail locally and send it when it can. It is not a good idea to have things like cron jobs get stuck or lose their output because a remote SMTP server was unreachable.
On Thu, 2004-04-01 at 20:52, Chris Adams wrote:
Once upon a time, Jeremy Katz katzj@redhat.com said:
Heh, that's just sick. How about my statement holding for when the clients are set up correctly? :-) (ie, if you don't use local sendmail and just do smtp, then local /var/spool isn't needed)
Way too many programs expect to be able to call /usr/sbin/sendmail to assume everything will use SMTP. And really, that is how it should be; why should every program be required to have an SMTP client built-in?
The nice thing about that is that you are pretty much guaranteed that you can send mail at any time, even if the network is down. Sendmail (or another local mailer) will queue the mail locally and send it when it can. It is not a good idea to have things like cron jobs get stuck or lose their output because a remote SMTP server was unreachable.
I think we have to assume that a managed read-only OS image sort of deployment would have some limitations in possible configurations and what apps could do. After all the whole point is to lock things down.
One setup would be that each user has an outgoing mail queue in their home directory, since homedir already has to be writeable by the user and gets backed up and so forth. Surely you could provide a /usr/sbin/sendmail that worked this way.
A queue in /var is suboptimal because it partially defeats the purpose of the deployment model - it leaves per-machine state to be corrupted, backed up, hacked, etc.
Havoc
On Fri, 2 Apr 2004 15:22, Havoc Pennington hp@redhat.com wrote:
One setup would be that each user has an outgoing mail queue in their home directory, since homedir already has to be writeable by the user and gets backed up and so forth. Surely you could provide a /usr/sbin/sendmail that worked this way.
I'm not sure that the user should require write access to their own home directory, I can think of quite a few cases where denying such access is desirable. But it's a reasonable trade-off.
The next issue is, how do we get the data out of the user home dir and send it via SMTP? Do we have a system cron job that goes through user home directories? If so we would have to make sure it changes it's UID to the user in question first so sym-link attacks against other users can't be done. We would also probably want to deny read access to sym-links in SE Linux policy.
If we don't have a system cron job we could have a script run on startup (same security issues as a system cron job) and have the "sendmail" program put itself in the background to keep re-trying the delivery. Of course as sendmail will run in the user context a "slay" operation or a temporary problem (such as OOM) will inconveniently stop mail delivery for that user until the next time the machine is rebooted or the next time that they send a message. So it seems that a system cron job to go through all users' directories is the best solution.
Another issue is what happens when the user runs out of quota. We want the "sendmail" process to run in the user context on non-SE systems so it can't do any harm, but that means that it gets the same quota. It would be annoying if the user ran a cron job which used up all their quota and then rendered itself unable to mail a warning message about being unable to work due to lack of quota... Of course on SE Linux we can have a SUID program that is restricted by SE Linux policy, but we do want it to be reasonably secure on non-SE machines too.
I think that any solution along these lines will have some trade-offs, but they will be worth it for some users and it will be a good thing to offer.
Hi Stephen,
The other version was one that would partition the laptop disk into 'mirrors' of itself.
I do something like this on a server, to be able to boot back into a known good state if an update ruins the system.
/boot -- 1 I think
In my setup I use two boot partitions (or actually /boot is part of /1 and /2). This is especially useful when doing kernel updates (instead of installs), like SuSE does.
/1 /2 /home -- 1 I think
Yes, user data is shared. Also share /var/log and /var/spool (and /srv), but not /var/lib (rpmdb etc). Another proof of how messy /var is...
boot is set up to boot into say /1 the first time, and then the asyncd updates /2 to whatever the network says it should be.
I just rsync the known good system to /mnt/backsys (which is /2) before an update, but then my setup is used to be able to roll back, not forward :) .
Grub is changed appropriately
In this roll back setup it is also important to adjust /etc/fstab according to the / partition. It's an integral part of the rsync scriplet I use. Seems to work flawlessly, but luckily I never had to rely on it (knock on wood ;) .
Leonard.
On Thu, 1 Apr 2004, Jeremy Katz wrote:
On Thu, 2004-04-01 at 15:46 -0700, Stephen Smoogen wrote:
The boxes were configured to use the local SMTP for some reason (I dont know.. I just had to debug the problem). Thus the mail went from client -> sendmail/var/spool/clientmqueue -> power-outage ooops
Heh, that's just sick. How about my statement holding for when the clients are set up correctly? :-) (ie, if you don't use local sendmail and just do smtp, then local /var/spool isn't needed)
The counter argument from the guy in suspenders and a beard to his knees is that 'when the hell did I get a windows box? Unix is better than that.' :).
So yes, the ability to have it, perfectly reasonable. Having it as the general case, perhaps overkill.
I think it is reasonable for a completely new environment to not have it because you can mandate clients etc. For existing large environments where people expect 40 year old editors written in Fortran to still work... lets just say exceptions become the rule :(.
On Fri, 2 Apr 2004, Havoc Pennington wrote:
On Thu, 2004-04-01 at 20:52, Chris Adams wrote:
Once upon a time, Jeremy Katz katzj@redhat.com said:
Heh, that's just sick. How about my statement holding for when the clients are set up correctly? :-) (ie, if you don't use local sendmail and just do smtp, then local /var/spool isn't needed)
Way too many programs expect to be able to call /usr/sbin/sendmail to assume everything will use SMTP. And really, that is how it should be; why should every program be required to have an SMTP client built-in?
The nice thing about that is that you are pretty much guaranteed that you can send mail at any time, even if the network is down. Sendmail (or another local mailer) will queue the mail locally and send it when it can. It is not a good idea to have things like cron jobs get stuck or lose their output because a remote SMTP server was unreachable.
I think we have to assume that a managed read-only OS image sort of deployment would have some limitations in possible configurations and what apps could do. After all the whole point is to lock things down.
One setup would be that each user has an outgoing mail queue in their home directory, since homedir already has to be writeable by the user and gets backed up and so forth. Surely you could provide a /usr/sbin/sendmail that worked this way.
A queue in /var is suboptimal because it partially defeats the purpose of the deployment model - it leaves per-machine state to be corrupted, backed up, hacked, etc.
How is printing done? How do cron jobs mail when a services home directory may not exist and the shell is nologin? Not trying to poke holes as much as think things out-loud. I wonder if queues should go under /var at all?
On Fri, 2 Apr 2004, Stephen Smoogen wrote:
On Fri, 2 Apr 2004, Havoc Pennington wrote:
A queue in /var is suboptimal because it partially defeats the purpose of the deployment model - it leaves per-machine state to be corrupted, backed up, hacked, etc.
How is printing done? How do cron jobs mail when a services home directory may not exist and the shell is nologin? Not trying to poke holes as much as think things out-loud. I wonder if queues should go under /var at all?
Actually, I think I am needing what the deployment model is and what it is for... that would help me get my head around it and what would need to be done. I may have a solution to the conundrum, but it needs a better idea of what is wanted.
On Thu, Apr 01, 2004 at 12:03:16PM +0200, Nicolas Mailhot wrote:
Well, let people in the know argue for /media if they want it. So far no one here seems to have understood what it's supposed to win over /mnt.
The FHS actually gives the rationalization: having mount points as subdirectories under /mnt conflicts with an allegedly widespread practice of using /mnt itself as a temporary mountpoint.
On Friday 02 April 2004 11:40, Matthew Miller wrote:
The FHS actually gives the rationalization: having mount points as subdirectories under /mnt conflicts with an allegedly widespread practice of using /mnt itself as a temporary mountpoint.
Alleged. Thats just it. I haven't ran across anybody who uses Linux that uses /mnt as a mountpoint. Everybody I've talked to and worked with will create their own temp dir under /mnt and mount things there.
On Fri, 2004-04-02 at 21:40, Matthew Miller wrote:
On Thu, Apr 01, 2004 at 12:03:16PM +0200, Nicolas Mailhot wrote:
Well, let people in the know argue for /media if they want it. So far no one here seems to have understood what it's supposed to win over /mnt.
The FHS actually gives the rationalization: having mount points as subdirectories under /mnt conflicts with an allegedly widespread practice of using /mnt itself as a temporary mountpoint.
"/mnt, the one singular temporary mount point you'll ever need", if they really say that, I'll withhold my opinion about their way of thoughts.
Nils
On Fri, Apr 02, 2004 at 11:41:30AM -0800, Jesse Keating wrote:
Alleged. Thats just it. I haven't ran across anybody who uses Linux that uses /mnt as a mountpoint. Everybody I've talked to and worked with will create their own temp dir under /mnt and mount things there.
Hmmm....
Maybe I shouldn't make a fool of myself in public ;) but I used to, at some point in the past, use /mnt itself as a mountpoint. However, that was several years ago; nowadays I create subdirectories in /mnt like most other Linux users.
Using /mnt directly is often done on other Unix-like operating systems, so anybody still doing that today is probably coming over from another Unix-like OS. (For instance, I'm logged into a Solaris 8 box in another xterm, and I just checked if /mnt there has subdirectories. It doesn't.)
-Barry K. Nathan barryn@pobox.com
On Fri, Apr 02, 2004 at 11:41:30AM -0800, Jesse Keating wrote: Content-Description: signed data
Alleged. Thats just it. I haven't ran across anybody who uses Linux that uses /mnt as a mountpoint. Everybody I've talked to and worked with will create their own temp dir under /mnt and mount things there.
/media actually went to a poll and a vote with the various distros. Its a pretty clear split between the /mnt/foo people and the others so they picked one. Unfortunately half the people I know who run SuSE seem to keep their movies and mp3 files in /media instead 8)
On Friday 02 April 2004 21:41, Jesse Keating wrote:
Alleged. Thats just it. I haven't ran across anybody who uses Linux that uses /mnt as a mountpoint. Everybody I've talked to and worked with will create their own temp dir under /mnt and mount things there.
Fearing to warm up the old discussion, A quick look at some of the Linux kernel Documentation/ directory reveals that most examples assume you're using /mnt as a single mountpoint. Not that I think you should do it that way, but I think that shows it's not too unusual. Agreed, RedHat didn't, but a lot of other distros seem to do it that way.
Cheers, Kai
On Sat, Apr 03, 2004 at 11:38:26AM +0200, Kai Blin wrote:
On Friday 02 April 2004 21:41, Jesse Keating wrote:
Alleged. Thats just it. I haven't ran across anybody who uses Linux that uses /mnt as a mountpoint. Everybody I've talked to and worked with will create their own temp dir under /mnt and mount things there.
Fearing to warm up the old discussion, A quick look at some of the Linux kernel Documentation/ directory reveals that most examples assume you're using /mnt as a single mountpoint. Not that I think you should do it that way, but I think that shows it's not too unusual. Agreed, RedHat didn't, but a lot of other distros seem to do it that way.
Red Hat has an empty directory called "/mnt" and some people use it to mount single further fs, some add further subdirs to mount more media.
By changing from "/mnt" to "/media" you have the same setup and anyone can choose to use it how they like. As Alan Cox said, some might choose to always mount their mp3 files to /media.
FHS helps a lot to set common rules for applications and standardize them, it won't be able to educate all users or tell them how to use their distribution.
Maybe "/srv" has more items on the cons side. What does debian and gentoo do on that side?
greetings,
Florian La Roche
hey all,
i've just installed FC2 and enabled the default SELinux security, etc. I've been having problems trying to run system apps that require root verification/authentication in Gnome. Is this error w/ genome only?
thanks, paul
ps: i will download ximian and install KDE from the disks to test this out
----- Original Message ----- From: "Aaron Matteson" fedora-devel@cryptosystem.us To: "Development discussions related to Fedora Core" fedora-devel-list@redhat.com Sent: Thursday, April 01, 2004 12:45 AM Subject: Re: Future: fhs 2.3 compliance for fc3
Dan Burcaw became daring and sent these 0.7K bytes,
On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote:
On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote:
On Wed, 2004-03-31 at 01:15, Shahms King wrote:
/media - all the removable media and silliness there.
And why isn't /mnt adequate for removable media?
I don't think /mnt has anything wrong with it, but FHS specifies
that
/media is a better name for a removable device and indeed, /media is what SuSE uses.
If SuSe decides to jump off the Brooklyn Bridge, are we expected to blindly follow?
Is SuSE doing something reason not to do it in Fedora/RHEL, etc?
Now, in english please?
-- 0 1 0 Aaron M Matteson - 0xD144B7FF 0 0 1 CCNA 1 1 1 Windows/Linux C++/C# Developer
The engineer in neither optimist nor pessimist. He sees the proverbial half-full/empty glass and says, "The glass is twice as big as there is and need for it to be."
http://cryptosystem.us/ - Project http://cryptosystem.us/blog/ - Blog
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
Also,
an error box pops up with "user known" or "unknown user"
-paul
----- Original Message ----- From: "Paul Rigor" pryce@ucla.edu To: "Development discussions related to Fedora Core" fedora-devel-list@redhat.com Sent: Monday, April 05, 2004 5:25 PM Subject: Fedora test 2: SELinux is problematic
hey all,
i've just installed FC2 and enabled the default SELinux security, etc.
I've
been having problems trying to run system apps that require root verification/authentication in Gnome. Is this error w/ genome only?
thanks, paul
ps: i will download ximian and install KDE from the disks to test this out
----- Original Message ----- From: "Aaron Matteson" fedora-devel@cryptosystem.us To: "Development discussions related to Fedora Core" fedora-devel-list@redhat.com Sent: Thursday, April 01, 2004 12:45 AM Subject: Re: Future: fhs 2.3 compliance for fc3
Dan Burcaw became daring and sent these 0.7K bytes,
On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote:
On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote:
On Wed, 2004-03-31 at 01:15, Shahms King wrote:
> /media - all the removable media and silliness there.
And why isn't /mnt adequate for removable media?
I don't think /mnt has anything wrong with it, but FHS specifies
that
/media is a better name for a removable device and indeed, /media
is
what SuSE uses.
If SuSe decides to jump off the Brooklyn Bridge, are we expected to blindly follow?
Is SuSE doing something reason not to do it in Fedora/RHEL, etc?
Now, in english please?
-- 0 1 0 Aaron M Matteson - 0xD144B7FF 0 0 1 CCNA 1 1 1 Windows/Linux C++/C# Developer
------------------------------------------------------------------------
The engineer in neither optimist nor pessimist. He sees the proverbial half-full/empty glass and says, "The glass is twice as big as there is and need for it to be."
------------------------------------------------------------------------
http://cryptosystem.us/ - Project http://cryptosystem.us/blog/ - Blog
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
I've seen that few times - with SELinux disabled. For me - it only happens when logging out of gnome after having run yum update
On Mon, 2004-04-05 at 17:56, Paul Rigor wrote:
Also,
an error box pops up with "user known" or "unknown user"
-paul
On Mon, Apr 05, 2004 at 05:25:15PM -0700, Paul Rigor wrote:
i've just installed FC2 and enabled the default SELinux security, etc. I've been having problems trying to run system apps that require root verification/authentication in Gnome. Is this error w/ genome only?
Its a knwon bug (if you log in as root they should work fine).
Alan
On Tue, Apr 06, 2004 at 09:09:31AM -0400, Alan Cox wrote:
i've just installed FC2 and enabled the default SELinux security, etc. I've been having problems trying to run system apps that require root verification/authentication in Gnome. Is this error w/ genome only?
Its a knwon bug (if you log in as root they should work fine).
Or presumably they work if you use sudo....
yes, i can run the apps when i invoke them as a superuser... but how come the authentication doesn't "stick" while in graphical mode? Do programs need to be written in order to retain "access" rights? I dont wanna be running a gui under root in order to perform updates etc...
Thanks, Paul
PS: I'm dumb (that and lazy)... is there a site explaining how FC2 implements SELinux? Are their resources regarding setting up policies?
At 08:32 PM 4/6/2004, you wrote:
On Tue, Apr 06, 2004 at 09:09:31AM -0400, Alan Cox wrote:
i've just installed FC2 and enabled the default SELinux security, etc. I've been having problems trying to run system apps that require root verification/authentication in Gnome. Is this error w/ genome only?
Its a knwon bug (if you log in as root they should work fine).
Or presumably they work if you use sudo....
-- Matthew Miller mattdm@mattdm.org http://www.mattdm.org/ Boston University Linux ------> http://linux.bu.edu/
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
_________ Paul Rigor pryce@ucla.edu Go Bruins!
Matthew Miller wrote:
On Tue, Apr 06, 2004 at 09:09:31AM -0400, Alan Cox wrote:
i've just installed FC2 and enabled the default SELinux security, etc. I've been having problems trying to run system apps that require root verification/authentication in Gnome. Is this error w/ genome only?
Its a knwon bug (if you log in as root they should work fine).
Or presumably they work if you use sudo....
We have put in several fixes in usermod, rhn and policy to make this work.
Dan
Harald Hoyer wrote:
Florian La Roche wrote:
Red Hat has an empty directory called "/mnt" and some people use it to mount single further fs, some add further subdirs to mount more media.
some people like kudzu create directories name "cdrom" and "floppy" there :)
There even have been some proposed corrections to the FHS 2.3 which didn't make it into the final version which actually more precisely define how /mnt can/should look like.
I agree with most people that in the really old days /mnt might have been used as single temporary mount point. But with the same argument a lot of other old cruft could be argued to keep on existing (which luckly often doesn't anymore).
On the other hand, having a /media directory surely doesn't hurt, but assuming that /mnt doesn't contain any subdirectories is plainly wrong IMHO.
/svr again seems to make quite a bit of sense to me as /var really contains some things right now that rightfully don't belong there resp. where there hasn't been a place to put some of these things properly yet.
I'll try to get a list compiled of stuff that might need fixing and either fix them myself or convince the appropriate package maintainers to fix them. :-)
Read ya, Phil
Hi,
Are there plans to include other filesystems during anaconda? How about including reiserfs? I've had to manually create this filesystem... it's plug-and-chug, but tedious.
Thanks, Paul Rigor pryce@ucla.edu Go Bruins! Go FC!
How easy is it to switch to X.org's X11 from the current FC1 distro? Yum (and its user) is sorta dumb.
thanks, Paul Rigor pryce@ucla.edu Go Bruins!! Go FC!!
reiserfs doesn't work with SELinux unless you use an unsupported patch.
On Wed, 2004-04-07 at 17:13, Paul Rigor wrote:
Hi,
Are there plans to include other filesystems during anaconda? How about including reiserfs? I've had to manually create this filesystem... it's plug-and-chug, but tedious.
Thanks, Paul Rigor pryce@ucla.edu Go Bruins! Go FC!
I recently learned the hard way that tmpfs is not supported either. Probably most of the filesystems do not support extended attributes yet.
Michael A. Peters wrote:
reiserfs doesn't work with SELinux unless you use an unsupported patch.
On Wed, 2004-04-07 at 17:13, Paul Rigor wrote:
Hi,
Are there plans to include other filesystems during anaconda? How about including reiserfs? I've had to manually create this filesystem... it's plug-and-chug, but tedious.
Thanks, Paul Rigor pryce@ucla.edu Go Bruins! Go FC!
I wouldn't do it if you don't have a few hours to fix possible problems. I did it using apt-get. Just apt-get update; apt-get install ...; What you'll want to do is something like rpm -qa |grep XFree Then fill in the ... above with xorg-x11-* for every thing you have XFree86-* installed already. It should say XFree86-* replaced, 0 removed. If it wants to remove things that you need, you should cancel. You may need to upgrade kde/gnome at the same time. After its installed, you may want to do an apt-get --reinstall install xorg-x11-*, where * are the xorg packages you picked. This reinstall was necessary in the first release because the removal of XFree86 happened afterward and caused some problems. Theoretically it shouldn't be necessary anymore, but it takes less than 5 minutes on most machines, so it should be quick and safe.
You should be done at that point, but problems may insue. Your favorite graphics driver may fail, and you may need to use an older kernel or switch to VESA or fbdev or something. You may need to remove (backup) /etc/X11/XF86Config, the use system-config-something to rebuild it. That "something" is not coming to me. It was something like "graphics", or "gui", but not X11 or xfree86, if I recall. Problems are not expected, but they may occur, so be ready.
-Eric Hattemer
Paul Rigor wrote:
How easy is it to switch to X.org's X11 from the current FC1 distro? Yum (and its user) is sorta dumb.
thanks, Paul Rigor pryce@ucla.edu Go Bruins!! Go FC!!
Thanks!
-Paul Rigor
----- Original Message ----- From: "Eric Hattemer" hattenator@imapmail.org To: "Development discussions related to Fedora Core" fedora-devel-list@redhat.com Sent: Wednesday, April 07, 2004 6:11 PM Subject: Re: Xfree86 v. X11-X.org
I wouldn't do it if you don't have a few hours to fix possible problems. I did it using apt-get. Just apt-get update; apt-get install ...; What you'll want to do is something like rpm -qa |grep XFree Then fill in the ... above with xorg-x11-* for every thing you have XFree86-* installed already. It should say XFree86-* replaced, 0 removed. If it wants to remove things that you need, you should cancel. You may need to upgrade kde/gnome at the same time. After its installed, you may want to do an apt-get --reinstall install xorg-x11-*, where * are the xorg packages you picked. This reinstall was necessary in the first release because the removal of XFree86 happened afterward and caused some problems. Theoretically it shouldn't be necessary anymore, but it takes less than 5 minutes on most machines, so it should be quick and safe.
You should be done at that point, but problems may insue. Your favorite graphics driver may fail, and you may need to use an older kernel or switch to VESA or fbdev or something. You may need to remove (backup) /etc/X11/XF86Config, the use system-config-something to rebuild it. That "something" is not coming to me. It was something like "graphics", or "gui", but not X11 or xfree86, if I recall. Problems are not expected, but they may occur, so be ready.
-Eric Hattemer
Paul Rigor wrote:
How easy is it to switch to X.org's X11 from the current FC1 distro?
Yum
(and its user) is sorta dumb.
thanks, Paul Rigor pryce@ucla.edu Go Bruins!! Go FC!!
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
Thanks. This is a bummer then. Unless I use selinux=0 when I boot. I'll just have to watch out for that 'checkbox' when installing FC2
Thanks, Paul
----- Original Message ----- From: "Warren Togami" warren@togami.com To: "Development discussions related to Fedora Core" fedora-devel-list@redhat.com Sent: Wednesday, April 07, 2004 5:50 PM Subject: Re: ReiserFS(v3,v4) vs. Ext3
I recently learned the hard way that tmpfs is not supported either. Probably most of the filesystems do not support extended attributes yet.
Michael A. Peters wrote:
reiserfs doesn't work with SELinux unless you use an unsupported patch.
On Wed, 2004-04-07 at 17:13, Paul Rigor wrote:
Hi,
Are there plans to include other filesystems during anaconda? How about including reiserfs? I've had to manually create this filesystem... it's plug-and-chug, but tedious.
Thanks, Paul Rigor pryce@ucla.edu Go Bruins! Go FC!
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Wed, 2004-04-07 at 17:13 -0700, Paul Rigor wrote:
Are there plans to include other filesystems during anaconda? How about including reiserfs? I've had to manually create this filesystem... it's plug-and-chug, but tedious.
anaconda actually has most of the code, it's just not on by default right now. There are a number of variables that just make it hard to get it all tested and verify that things don't break to enable it unconditionally. Also, most filesystems don't support the needed security xattrs required for SELinux -- I know that reiserfs does not at present, for example.
I'd love to enable this, it's just a matter of testing and avoiding paths that we know are going to cause problems :/
Jeremy
On Wed, 7 Apr 2004, Michael A. Peters wrote:
reiserfs doesn't work with SELinux unless you use an unsupported patch.
Actually, it looks like patches to provide SELinux support for reiserfs v3 are being submitted to Andrew Morton's kernel tree (i.e. a reasonable chance that this will be in 2.6 soon).
- James
On Wed, 2004-04-07 at 17:15 -0700, Paul Rigor wrote:
How easy is it to switch to X.org's X11 from the current FC1 distro? Yum (and its user) is sorta dumb.
what problems are you having with yum upgrading to those packages (other than it's a big shift that you're doing, partially)
-sv
I know this is a belated reply, I just wanted to throw in some change.
I don't think talking about whether or not we like them is useful here. It is the fhs and fedora core should be compliant with it.
Your comment expresses more dogmatism than I'm comfortable with.
I was a strong advocate for FSSTND and FHS compliance in the early days [and am still a supporter of those early standards, especially FSSTND]; but I must say I've become less and less impressed by FHS with each new revision (especially lately [e.g., moving around /var/spool/mail, /media, .../misc directories scattered everywhere, etc.]).
If I remember correctly, the free software world is about freedom and self-forming community cooperation. If newer versions of FHS don't pass the tests of natural selection in such a community, they'll cease to be standards, and a new ideas will fill FHS' place.
I support the general idea of FHS, but feel they're sorta losin' sight. And if they dictate from on high a bunch of nonsense, not many people are going to listen.
Peace out,
Derek
On Thu, 8 Apr 2004 11:39, Jeremy Katz katzj@redhat.com wrote:
Also, most filesystems don't support the needed security xattrs required for SELinux -- I know that reiserfs does not at present, for example.
XFS is a file system to consider, it has full SE Linux support in recent 2.6 kernels.
The only thing to note with XFS is that it's strongly recommended that you use a 512 byte block size.
On Mon, Apr 12, 2004 at 08:49:18PM +1000, Russell Coker wrote: [quote reformatted to reduce width]
The only thing to note with XFS is that it's strongly recommended that you use a 512 byte block size.
Where did you find that recommendation?
The closest thing I've found to an XFS block size recommendation is this, which generally suggests 4K blocks for filesystems greater than 100MB in size: http://www.cray.com/craydoc/manuals/S-2377-22/html-S-2377-22/z1029460436.htm...
Also, the default block size is 4K.
-Barry K. Nathan barryn@pobox.com
On Tue, 13 Apr 2004 04:13, "Barry K. Nathan" barryn@pobox.com wrote:
On Mon, Apr 12, 2004 at 08:49:18PM +1000, Russell Coker wrote: [quote reformatted to reduce width]
The only thing to note with XFS is that it's strongly recommended that you use a 512 byte block size.
Where did you find that recommendation?
Sorry that was a mistake. I meant to say a "512 byte Inode size".
devel@lists.stg.fedoraproject.org
-
Aaron Matteson -
Alan Cox -
Aleksey Nogin -
Barry K. Nathan -
Bill Nottingham -
Carwyn Edwards -
Chris Adams -
Chris Kloiber -
Dan Burcaw -
Daniel J Walsh -
Dave Jones -
Dax Kelson -
Derek P. Moore -
Eric Hattemer -
Felipe Alfaro Solana -
Florian La Roche -
Harald Hoyer -
Havoc Pennington -
Hugo van der Kooij -
James Morris -
Jeremy Katz -
Jesse Keating -
Kai Blin -
Leonard den Ottolander -
Matthew Miller -
Michael A. Peters -
Nicolas Mailhot -
Nils Philippsen -
Panu Matilainen -
Pau Aliagas -
Paul Rigor -
Phil Knirsch -
Robert Marcano -
Russell Coker -
seth vidal -
Shahms King -
Stephen Smoogen -
Trever L. Adams -
Warren Togami