-<p>One of the new features in the next Debian/Lenny based release of
-Debian Edu/Skolelinux, which is scheduled for release in the next few
-days, is automatic configuration of the service monitoring system
-Nagios. The previous release had automatic configuration of trend
-analysis using Munin, and this Lenny based release take that a step
-further.</p>
-
-<p>When installing a Debian Edu Main-server, it is automatically
-configured as a Munin and Nagios server. In addition, it is
-configured to be a server for the
-<a href="http://wiki.debian.org/DebianEdu/HowTo/SiteSummary">SiteSummary
-system</a> I have written for use in Debian Edu. The SiteSummary
-system is inspired by a system used by the University of Oslo where I
-work. In short, the system provide a centralised collector of
-information about the computers on the network, and a client on each
-computer submitting information to this collector. This allow for
-automatic information on which packages are installed on each machine,
-which kernel the machines are using, what kind of configuration the
-packages got etc. This also allow us to automatically generate Munin
-and Nagios configuration.</p>
-
-<p>All computers reporting to the sitesummary collector with the
-munin-node package installed is automatically enabled as a Munin
-client and graphs from the statistics collected from that machine show
-up automatically on http://www/munin/ on the Main-server.</p>
-
-<p>All non-laptop computers reporting to the sitesummary collector are
-automatically monitored for network presence (ping and any network
-services detected). In addition, all computers (also laptops) with
-the nagios-nrpe-server package installed and configured the way
-sitesummary would configure it, are monitored for full disks, software
-raid status, swap free and other checks that need to run locally on
-the machine.</p>
-
-<p>The result is that the administrator on a school using Debian Edu
-based on Lenny will be able to check the health of his installation
-with one look at the Nagios settings, without having to spend any time
-keeping the Nagios configuration up-to-date.</p>
-
-<p>The only configuration one need to do to get Nagios up and running
-is to set the password used to get access via HTTP. The system
-administrator need to run "<tt>htpasswd /etc/nagios3/htpasswd.users
-nagiosadmin</tt>" to create a nagiosadmin user and set a password for
-it to be able to log into the Nagios web pages. After that,
-everything is taken care of.</p>
+<p>My file system sematics program
+<a href="http://people.skolelinux.org/pere/blog/Testing_if_a_file_system_can_be_used_for_home_directories___.html">presented
+a few days ago</a> is very useful to verify that a file system can
+work as a unix home directory,and today I had to extend it a bit. I'm
+looking into alternatives for home directory access here at the
+University of Oslo, and one of the options is sshfs. My friend
+Finn-Arne mentioned a while back that they had used sshfs with Debian
+Edu, but stopped because of problems. I asked today what the problems
+where, and he mentioned that sshfs failed to handle umask properly.
+Trying to detect the problem I wrote this addition to my fs testing
+script:</p>
+
+<pre>
+mode_t touch_get_mode(const char *name, mode_t mode) {
+ mode_t retval = 0;
+ int fd = open(name, O_RDWR|O_CREAT|O_LARGEFILE, mode);
+ if (-1 != fd) {
+ unlink(name);
+ struct stat statbuf;
+ if (-1 != fstat(fd, &statbuf)) {
+ retval = statbuf.st_mode & 0x1ff;
+ }
+ close(fd);
+ }
+ return retval;
+}
+
+/* Try to detect problem discovered using sshfs */
+int test_umask(void) {
+ printf("info: testing umask effect on file creation\n");
+
+ mode_t orig_umask = umask(000);
+ mode_t newmode;
+ if (0666 != (newmode = touch_get_mode("foobar", 0666))) {
+ printf(" error: Wrong file mode %o when creating using mode 666 and umask 000\n",
+ newmode);
+ }
+ umask(007);
+ if (0660 != (newmode = touch_get_mode("foobar", 0666))) {
+ printf(" error: Wrong file mode %o when creating using mode 666 and umask 007\n",
+ newmode);
+ }
+
+ umask (orig_umask);
+ return 0;
+}
+
+int main(int argc, char **argv) {
+ [...]
+ test_umask();
+ return 0;
+}
+</pre>
+
+<p>Sure enough. On NFS to a netapp, I get this result:</p>
+
+<pre>
+Testing POSIX/Unix sematics on file system
+info: testing symlink creation
+info: testing subdirectory creation
+info: testing fcntl locking
+ Read-locking 1 byte from 1073741824
+ Read-locking 510 byte from 1073741826
+ Unlocking 1 byte from 1073741824
+ Write-locking 1 byte from 1073741824
+ Write-locking 510 byte from 1073741826
+ Unlocking 2 byte from 1073741824
+info: testing umask effect on file creation
+</pre>
+
+<p>When mounting the same directory using sshfs, I get this
+result:</p>
+
+<pre>
+Testing POSIX/Unix sematics on file system
+info: testing symlink creation
+info: testing subdirectory creation
+info: testing fcntl locking
+ Read-locking 1 byte from 1073741824
+ Read-locking 510 byte from 1073741826
+ Unlocking 1 byte from 1073741824
+ Write-locking 1 byte from 1073741824
+ Write-locking 510 byte from 1073741826
+ Unlocking 2 byte from 1073741824
+info: testing umask effect on file creation
+ error: Wrong file mode 644 when creating using mode 666 and umask 000
+ error: Wrong file mode 640 when creating using mode 666 and umask 007
+</pre>
+
+<p>So, I can conclude that sshfs is better than smb to a Netapp or a
+Windows server, but not good enough to be used as a home
+directory.</p>
+
+<p>Update 2010-08-26: Reported the issue in
+<a href="http://bugs.debian.org/594498">BTS report #594498</a></p>
+
+<p>Update 2010-08-27: Michael Gebetsroither report that he found the
+script so useful that he created a GIT repository and stored it in
+<a href="http://github.com/gebi/fs-test">http://github.com/gebi/fs-test</a>.</p>
projects / homepage.git / blobdiff