https://bugzilla.novell.com/show_bug.cgi?id=285101#c1 Miklos Szeredi <mszeredi@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #1 from Miklos Szeredi <mszeredi@novell.com> 2007-06-18 08:12:51 MST --- (In reply to comment #0 from Stephan Kulow)

Doing this bug report to find out / document the reason we load the fuse module a) in our default selection b) that early in the boot process

The fuse module seems to waste time and memory on my system.

Any fuse filesystem is unusable without the fuse module first being loaded. The default was added, so that filesystems like sshfs, encfs, etc. work out of the box without having to do additional configuration. It is based on the assumption, that the fuse package is only installed if the user needs it's functionality. Why do you have the fuse package installed if you do not intend to use it? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c3 --- Comment #3 from Miklos Szeredi <mszeredi@novell.com> 2007-06-18 08:43:52 MST --- (In reply to comment #2 from Stephan Kulow)

libfuse.so.2 is needed by (installed) compiz.

I don't use compiz either on this very laptop, but it's installed by default. So is fuse. So is boot.fuse -> modprobe

Hmm, so fuse gets pulled in by some weird dependency. Not enabling by default will result in bug reports for "I have installed foofs, but it won't work". See bugs #179618, #222899, #223663 Do you have any other suggestion for solving this? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c5 Miklos Szeredi <mszeredi@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO --- Comment #5 from Miklos Szeredi <mszeredi@novell.com> 2007-06-18 09:25:08 MST --- (In reply to comment #4 from Stephan Kulow)

well, I don't know the reasons compiz requires libfuse, but splitting that package out of fuse would help there.

Right, that makes sense.

So sshfs would require fuse, the loaded module while compiz requires the library. But that doesn't mean fuse, the loaded module, is in the default selection.

According to compiz changelog, here's the culprit: - FUSE plugin that maps compiz options to a file-system and allow efficient manipulation of options by reading and writing files. Matthias, can you tell us, if this is some integral part of compiz, or an optional feature, that could be split into a separate package? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c8 --- Comment #8 from Miklos Szeredi <mszeredi@novell.com> 2007-06-18 10:15:28 MST --- (In reply to comment #7 from Stephan Kulow)

I just talked with Matthias (didn't know he was on NEEDINFO too :): it's an unused plugin and will be split into a subpackage not installed.

That sounds good.

But I think fuse package should be changed by two means: - split the library into a library package

I don't have strong opinions either way. Is there some policy in SUSE about subpackages?

- don't modprobe in a boot.*, but make it a normal rc script in runlevel 2 3 5

Well, in theory we can have fuse based filesystems mounted from /etc/fstab, which means, that the modprobe has to run before boot.localfs. But probably this is not very well thought out or tested yet. But if SUSE wants proper ntfs-3g support for example, this is something that needs to be looked at, and it means that fuse does need to be started early. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c11 --- Comment #11 from Miklos Szeredi <mszeredi@novell.com> 2007-06-19 06:36:09 MST --- (In reply to comment #10 from Stephan Kulow)

What speaks against fuse before .localfs btw is that its tool is from /usr

Right. That'll actually be fixed in fuse-2.7, as 'fusermount' will no longer be necessary if the mounter has enough privileges. As to individual filesystems, it should be decided on a case-by-case basis. Possibly ntfs-3g is something people would never want to use as a /usr partition, but maybe some other fuse based filesystem could be used as /usr. In that case the filesystem executable must necessarily reside on the root fs. So generally assuming the fuse module won't be needed till after boot is wrong I think. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c9 --- Comment #9 from Stephan Kulow <coolo@novell.com> 2007-06-18 13:02:55 MST --- http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy I don't think ntfs-3g needs to be mounted by .localfs. I doubt we will put /usr in there and user data can be mounted on demand - and on that demand we can also modprobe fuse, or somewhen later. Anyway, theory isn't really of interest for default boot :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. ---

https://bugzilla.novell.com/show_bug.cgi?id=285101 Stephan Kulow <coolo@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|mszeredi@novell.com |bk@novell.com Status|ASSIGNED |NEW -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c15 --- Comment #15 from Miklos Szeredi <mszeredi@novell.com> 2007-07-27 11:20:52 MST --- (In reply to comment #14 from Bernhard Kaindl)

Having been asked by coolo to take charge, I put together what we should do:

1) Changes to the init script, also targetted for umounting fuse on shutdown: -----------------------------------------------------------------------------

I think from how I understand the last comments in this report and bug 293429 (fuse should be stopped before the fuse filesystems get killed on shutdown), we have no problem to move fuse rc script from boot.fuse to normal rc script in runlevels 2 3 and 5.

OK, I concur on this one.

2) Possible measures to not start fuse when not needed or not requested

2.1) Start fuse on demand. I don't know how to do this best, at least in a default SuSE setup, it should in theory be possible, but loading a module needs root privileges:

2.1.1) On openSUSE, /usr/bin/fusermount is suid-root for all users when the default /etc/permissions.easy is used by SuSEconfig.permssions:

$ grep fusermount /etc/permissions* /etc/permissions.easy:/usr/bin/fusermount root:trusted 4755 /etc/permissions.secure:/usr/bin/fusermount root:trusted 4750 /etc/permissions.paranoid:/usr/bin/fusermount root:trusted 0755

As %run_permissions is in %post of fuse, that is also being taken care of when the fuse rpm is manually installed.

Thus, fusermount could be used to trigger the module load and could also mount the fusectl filesystem (like ntfs-3g is doing when it has root privileges - it also creates /dev/fuse in case udev is not running)

This is wrong. In the (not so) long run we want to get rid of suid fusermount. The unprivileged mount patches are already in -mm, so 2.6.24 is not unrealistic. This may not make it into OpenSUSE-10.3, but I think relying on fusermount to load the module is not a good direction to take.

This will not be neccessary for ntfs-3g tough, because as of coolo's comment to bug 293429#c2, it seems that we'll go with a suid ntfs-3g.

2.2) Start fuse only when filesystems which use fuse are installed, so we could for examle move the %{insserv_force_if_yast boot.fuse} from %post of fuse to the %post of curlftpfs encfs fuseiso fusepod fusesmb gphotofs obexfs sshfs and wdfs which means that then fuse is only started when they are installed.

No, I think there's no problem with unconditionally loading the module if the fuse package is installed. If the user doesn't want this, then (s)he should remove the package. The _real_ bug in this case was a wrong dependency on fuse, but that has been resolved, so I think this is not an issue any more.

Mentioned in the discussion has also been:

3) Split fuse into fuse and libfuse2. It would generally be advised by http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy to split fuse into fuse and libfuse2, but as libfuse calls fusermount and libulockmgr starts ulockmgr_server, libfuse2 will require fuse of the same version, so both rpms would need to be installed at once, because fuse automatically has a dependency on libfuse2. So to have any gain of splitting off libfuse2, which would normally be to be able to have two versions of libfuse installed, we'd need to have two fuse rpms installed also, which means that we'd have to add the SONAME major of fuse to the main rpm, which means that we'd have to use fuse2 and libfuse2 in order to have them coexist with fuse3 and libfuse3, but this also means that fusermount and ulockmgr_server need to be renamed to fusermount2 and ulockmgr_server2 a symlink would have to supply the default fusermount to the user. That symlink may be possibly be best provided by a new "fuse" rpm which just has the symlink and a possible man page, done like the current gcc rpm which symlinks to gcc42 and requires gcc42. Very complicated in the end.

The fusermount from fuse-3 should be compatible with the one from fuse-2. So there won't be a need to keep two versions of fusermount around. About ulockmgr: actually that's a completely separate thing from fuse, and should probably be packaged separately. I may make it a separate source package in the future.

It it worth it? - Does one need to support old fuse filesystems which still use fuse2 when we will switch to fuse3? Maybe, if we want to support users which have installed their own fuse filesystems and want to be able to update to say openSUSE 11.0 (or so) without breaking their self-installed fuse filesystems. But will the fuse module of the kernel still support fuse2 or may the API change without backwards compatibility?

Fuse-3 will not be ABI compatible, and probably won't be 100% API compatible either. So separate libraries will be needed, at least until filesystem are ported.

In addition, fuse3 would likely have to use fuse3 fstype and provide fusectl3 and would fuse3 then use a fuse3.ko, fuse3 fstype and use /sys/fs/fuse3/connections as mount point for it? I think only if it's done like this, a split would make sense. Wether to do it like this is I think the call of Miklos (as the developer of fuse).

The kernel interface will remain backward compatible. So this is not an issue. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c17 --- Comment #17 from Miklos Szeredi <mszeredi@novell.com> 2007-07-29 05:19:37 MST --- I disagreee, we don't _need_ this. We may want to do it because of optimization purposes. My personal opinion, is that not loading the fuse module on boot would be causing much more pain for users as well as packagers than the small gain in boot time and memory usage would warrant. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c19 --- Comment #19 from Miklos Szeredi <mszeredi@novell.com> 2007-07-30 05:07:25 MST --- If we can do it without a penalty in usability, fine. Otherwise it's not worth it. Decreasing boot time is a very worthy goal IMO, but the gain here is probably infinitesimally small. And there are just not enough similar gains to be had for this to make sense. If we _really_ want to achieve measurable results, we have to attack the problem were there are large gains to be had, namely hardware probing and disk seeking, and possibly the CPU time taken up by the boot scripts themselves. But you probably know much more about this, so I'll shut up ;) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c21 --- Comment #21 from Miklos Szeredi <mszeredi@novell.com> 2007-07-30 05:45:34 MST --- And I won't allow a regression in fuse usability in the name of "we want to decrease boot time by 0.1%". ;) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c23 --- Comment #23 from Bernhard Kaindl <bk@novell.com> 2007-07-30 10:06:47 MST --- Thanks Péter, you mentioned SMTP as one of the examples of a basic service which is started at boot. I have to disagree on that point because I use exim as MTA and by default - it's init script does not run at boot by default, and mail programs still send mails locally thru the provided /usr/sbin/sendmail and I have no SMTP running at all. This means that mails can't be sent through the SMTP port, but programs use /usr/sbin/sendmail just fine. So even though one can say that mail is the most basic service, sending mail through the sendmail mechanism works even without any initialization at boot. Having installed fuse because of some dependency does not meen automatically that the system administrator already wants users to be able to mount their own filesystems. Usability (requriement used by Miklos in comment #21 ) is another word for user-friendlyness, or for ease of use, but the aim for ease of use may potentially conflict with what the adminstrator allows the users to do. For you, fuse may be such a basic service that you need it on all your systems and do not want to chkconfig -a fuse;/etc/init.d/fuse start on all systems and you may not want to add that line to the FAQ (or add it to the message which gets printed when fuse is not loaded, unless it's really as widely required as printing, I'd still say that it should not be loaded by default simply because the fuse users are still (at least I guess so) rather a minority compared to all openSUSE users. While it's your everday use and while I believe that the initial security holes in fuse should be mostly ironed out now, filesystems mounted by users is IMHO still a rather unexplored field. For me, it seems to make little sense to initialize fuse on every boot when there is no rpm installed which would need to have it installed at boot, and I also think that it should be an administrator's willful decision to allow users to mount filesystems. A few years ago, free software distributions were indeed very lax when regarding starting services, e.g. it was standard configuration that inetd and SMTP were running and telnet access was enabled, even SMTP relaying was enabled by default often (which has given spammers an easy start), but over the years it has proven necessary to be more restrictive in what to start and what to permit by default. For sure, this has not improved usability, but I think it valid to think that not every system admin may want allow it's users to mount filesystems. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c25 --- Comment #25 from Miklos Szeredi <mszeredi@novell.com> 2007-07-30 10:40:51 MST --- Totally agreed about security points. However that is totally independent from the boot aspect, and should be controlled by permissions on fusermount or /dev/fuse and _not_ by refusing to load the module on boot. # /etc/permissions.easy is set up for the use in a standalone and single-user # installation to make things "work" out-of-the box. # Some of the settings might be considered somewhat lax from the security # standpoint. These aspects are handled differently in the permissions.secure # file. This quite clearly describes the "user friendly" mode, in which case loading the module on boot is necessary. We could optimize out the module loading in the other cases, but that would just add complexity without noticable gain. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c27 --- Comment #27 from Bernhard Kaindl <bk@novell.com> 2007-07-30 11:17:21 MST ---

...

* fuse2 - contains fusermount, mount.fuse, the rc script and docs I'd call the package just "fuse" or "fuse-utils".

Yes, didn't think that though. Indeed I think just "fuse" (or "fuse-utils, I'm not sure what is best) fuse or fuse-utils should be without version in the name because when fuse goes 3.x, an update upgrades the fuse or fuse-utils package to fuse-3.x and that works as fusermount of fuse-3.x will be compatible with libfuse2.

Otherwise this sounds fine. Do we want *fs packages to depend on the fuse package? Or should the user need to install fuse separately to have a working filesystem?

Normally, way we'd do such things this way: If a package is installed, it should be basically or mostly useable without having to install further packages, this is the whole point of having package dependices, so I'd say. As to what they should require, I think that instead of requiring "fuse" or "fuse-tools", they may (in case we may change the name of the package or split furhter) also require specifically fusermount, either by requiring /usr/bin/fusermount as path, but as they do not need it in a specific path, they may also require just have "fusermount" and the whichever package provides fusermount would then have "Provides: fusermount", independent of it's name. The label could also include the API of the fusermount requiured and provided, e.g. "fusermount-v2" would also be possible. At the moment, I think I prefer such provides/requires string with such API version added as that would give total freedom on which package provides it and it also means that one is free to drop that provides once that API is not longer provided or moved to a different package. I know this is very very generic, but this way the control is over the provides string and that's very flexible. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c29 --- Comment #29 from Bernhard Kaindl <bk@novell.com> 2007-07-30 11:59:23 MST --- Good, so we split fuse in libfuse2 (only the libs) and fuse, and add Requires: fuse to the *fs packages. If you like I can do that tomorrow, or I can leave it to you. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=285101#c31 --- Comment #31 from Bernhard Kaindl <bk@novell.com> 2007-08-12 05:00:49 MST --- The split is done, it has been checked into STABLE. changes of the check-in: +Fri Aug 10 13:41:37 CEST 2007 - bk@suse.de + +- branch off libfuse2 to avoid having to start fuse on boot (#285101) +- Add "Supplements: filesystem(fuse)" in case someone looks for fuse +- libulockmgr and ulockmgr_server are separate from fuse (#285101) I rebuilt all packages which use libfuse-devel with an mbuild of this fuse using mbuild -p and all look well. As agreed in the last 2 comments, I added Requires: fuse to the *fs packages which use fuse: curlftpfs encfs fuseiso fusepod fusesmb gphotofs obexfs sshfs wdfs I omitted compiz because fuse is not actively used by yet and because we do not want it to pull fuse into the list of packages which is usually installed. And I of course I omitted ntfs-3g. I copied them to /work/src/done/STABLE, so these packages are now pending check-in. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.