Re: [Fwd: Lockdown stuff]

[seth vidal <skvidal phy duke edu>]

> You mean home-directory-sharing/lockfile, right?

more or less, yes.

> There hasn't been recent discussion, simply because there isn't a likely
> volunteer to hack on it that I know of.

Catch me privately, I'd like to see if there are any possibilities of
incentivizing someone to look at this problem.

> GNOME 2.4 defaults to the lockfile in /tmp ; I don't know if that will
> result in more problems or less. It is however almost equivalent to
> having applications simply write to text files directly, which is the
> traditional method of doing configuration. The one reason it isn't is
> that a single app may have config in multiple files. So a possible
> short-term hack would be to do a file backend that puts each /apps/foo
> subdir in a single text file? That might be a simple thing to try that I
> just thought of to avoid funky states. Perhaps long-term it's even The
> Solution for the local files backend.

Well I'm hoping to be in a place to test gnome 2.4 in the not-so-distant
future on actual machines. I might be able to come up with a reasonable
answer to the /tmp locking fixing or not fixing things.

Has the /tmp locking changed from 2.2 to 2.4? If there are no gnome 1.X
apps in use and evo 1.4 does that free 2.2 from that concern?

I can move some of the machines I manage to galeon 1.3.X and gnumeric
1.1.20 (or whatever number the gnome 2.4 port is) if that's what is
needed to test this.

> My long-term plan is to simplify the gconf code quite a bit (for stuff
> like the logfile problem, just stop logging; gconfd should be a lot
> smaller by keeping less state; libgconf could also be significantly
> smaller). Then have two backends, one LDAP (working toward this, I
> finally read a book on it), and one plain files (but no longer assuming
> a single daemon accessing them; change-monitor and lock each file).

simpler seems to be a good idea for this daemon. It seems like a lot
went into gconf all at once and it's made discovering some of the
problems fairly complex. We've encountered a few problems we can't even
describe w/o a screenshot b/c all they are is a giant red x in a gnome
window with a few checkboxes.


> The without-redoing-all-of-gconf solution is probably to do only the
> backend part of this, to move change notification to the backend, and
> have some system where file changes by other daemons are noticed and
> each daemon sends out notifications. Probably you also need to lock each
> individual file while changing it, instead of just writing it
> atomically.
> 
> But of course then you're in file-locking hell again. ;-)

If gconf can get to a point where file locking is the only bug, then
pressure can be applied to the nfs people to get those bugs fixed and/or
to more testing to see if the locking under afs is just plainly more
reliable - or nfsv4.


> For the D-BUS cookie file, I have some code that doesn't use kernel
> locks, just has a really long timeout on a very briefly-held lockfile;
> maybe that is the right approach for the backend files.

Timeouts might make more sense considering the system could crash while
the lock is held - w/o a stateful daemon it makes tracking that problem
difficult.


>  - fix the session manager. I believe the session manager should be 
>    responsible for sanity-checking disk space on login, and also 
>    gracefully helping with multiple login if we can figure out how.

I was discussing with one of the folks I work with the possibility of
some simple python apps that run out of xinitrc.d. Do various things
like: check quota and alternately open up a vte to let them fix their
crap or, maybe load up python-gconf stuff and grouse around the users
gconf settings to fix stupid crap, or purge their old cache files or
whatever. 

For example: 
If they are just over quota but not within some % of the hard quota then
they get a warning, etc.

That isn't at the gnome-session level but it does help with the problem
and is very simple.

This is one of the reasons I wanted run-as-user-on-logout.d directory
for gnome. So I could do some cleanups AS the user BEFORE they lose
their fs/login credentials.

> Ultimately the multiple-login problem is probably best solved by _not_
> sharing homedirs, but instead using dedicated file shares, IMAP, LDAP,
> and other specialized servers. Or perhaps by having a network file
> system that sucked less, using the homedir as the all-singing way to
> keep your data on the network would be more robust.

If you'd like to do these same tests under afs I can give you data back.
I've got both nfs and afs infrastructures here at duke and can show you
what we've got. The long and short of it is - that while gnome can
change on 6 month timespans nfs changing or afs changing in those
time-frames is harder.

I'm not sure what other network file system options we've got - cifs, I
guess, but all the acls are weird.

I'm going to say this, I know it's annoying but: why does it seem like
kde does not suffer from this problem. Our multi-login kde users do not
seem to get into the lockfile-hell problem. Kde has its own set of
problems, but this isn't one of them, and I'm not terribly interested in
helping to fix the kde problems. :)

> Anyway, I can't begin to fix all this myself. I do want to get it fixed
> though. It would be very helpful to me if someone could adopt the menu
> problem, btw. ;-) Basically I want to polish up D-BUS and get it going,
> base a GConf reworking on that in addition to having that address many
> lifecycle/robustness issues, then tackle the session manager. I would
> also like to offload some of the RPMs I maintain and get a good
> maintainer for some of the packages I own.

What rpms do you maintain. I know some folks who aren't too bad w/rpm
maintenance, might be able to help.

> Ultimately I'm only going to be able to do 5% of the work myself.
> I don't even see how I'll get to finish the menu stuff at the moment,
> and I'm not keeping up with bugs on my modules.

I understand you're swamped, I'm knee deep in things too, sadly - but
maybe some mails like this are good way to help that problem. See if you
can itemize out some things that suck up your time that you think
someone else can do. It's worth a shot at least.

Any chance the ximian^Wnovellians will have any spare people to throw at
this problem in the not-so-distant future?

-sv