Calendar
QuicksearchArchivesCategoriesBlog AdministrationPowered byLizenz/LicenseDer Inhalt dieses Blogs ist © Copyright 2009 Ralf Ertzinger. Jegliche Reproduktion und Wiederverwertung nur mit schriftlicher Genehmigung des Autors. The content of this blog is © Copyright 2009 Ralf Ertzinger. |
Wednesday, December 30. 2009Adding new dynamic library dependencies to an existing objectDue to some developing I needed a "lighttpd":http://www.lighttpd.net with modmagnet enabled. modmagnet is a module which allows inserting of lua code into the request processing stream. This is a cool feature, and I was pleased to see that
Of course there is this small problem: 2009-12-29 23:29:31: (plugin.c.165) dlopen() failed for: /usr/lighttpd/1.4/lib/mod_magnet.soi ld.so.1: lighttpd: fatal: relocation error: file /usr/lighttpd/1.4/lib/mod_magnet.so: symbol luaL_checklstring: referenced symbol not found What this means is that there are unresolved symbols remaining in the code after the dymanic loader has done it's work, which should not happen. Let's look a the dynamic deps of the module. $ ldd /usr/lighttpd/1.4/lib/mod_magnet.so libsendfile.so.1 => /lib/libsendfile.so.1 libm.so.2 => /lib/libm.so.2 libresolv.so.2 => /lib/libresolv.so.2 libnsl.so.1 => /lib/libnsl.so.1 libsocket.so.1 => /lib/libsocket.so.1 libc.so.1 => /lib/libc.so.1 libmd.so.1 => /lib/libmd.so.1 libmp.so.2 => /lib/libmp.so.2 libscf.so.1 => /lib/libscf.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 libsmbios.so.1 => /usr/lib/libsmbios.so.1 Judging from the name of the missing symbol So what happened? Somehow (and I have no idea how) Sun managed to build a mod_magnet without linking it to the lua libraries at the end. Simply speaking, this is broken. Fortunately there is a way to fix this. Sun provides a utility called First show the existing DT_NEEDED records. $ elfedit mod_magnet.so mod_magnet2.so > dyn:value DT_NEEDED index tag value [0] NEEDED 0x5f9 libsendfile.so.1 [1] NEEDED 0x60a libm.so.2 [2] NEEDED 0x614 libresolv.so.2 [3] NEEDED 0x623 libnsl.so.1 [4] NEEDED 0x62f libsocket.so.1 [5] NEEDED 0x5d3 libc.so.1 This is basically the same list as above, with liblua.so notably lacking. Now add a new entry: > dyn:value -add -s DT_NEEDED liblua.so index tag value [34] NEEDED 0x63e liblua.so Now look at the new table, and save it. > dyn:value DT_NEEDED index tag value [0] NEEDED 0x5f9 libsendfile.so.1 [1] NEEDED 0x60a libm.so.2 [2] NEEDED 0x614 libresolv.so.2 [3] NEEDED 0x623 libnsl.so.1 [4] NEEDED 0x62f libsocket.so.1 [5] NEEDED 0x5d3 libc.so.1 [34] NEEDED 0x63e liblua.so > :write > :quit Looking at the $ ldd ./mod_magnet2.so libsendfile.so.1 => /lib/libsendfile.so.1 libm.so.2 => /lib/libm.so.2 libresolv.so.2 => /lib/libresolv.so.2 libnsl.so.1 => /lib/libnsl.so.1 libsocket.so.1 => /lib/libsocket.so.1 libc.so.1 => /lib/libc.so.1 liblua.so => /usr/lib/liblua.so libmd.so.1 => /lib/libmd.so.1 libmp.so.2 => /lib/libmp.so.2 libscf.so.1 => /lib/libscf.so.1 libdl.so.1 => /lib/libdl.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 libsmbios.so.1 => /usr/lib/libsmbios.so.1 Now the linker picks up the lua libraries. If the modified modmagnet.so is now put back into Now, this wasn't so hard, was it? Friday, December 25. 2009Changing the rpool disk in SolarisEver since my storage system was built there was one thing that annoyed me. The 2.5" hard disk drive that houses the operating system itself was lifted from an old notebook and had the annoying property of parking it's heads after five seconds of inactivity. Since ZFS writes to the disk quite often and regularily this led to a constant cycle of parking and unparking. This was certainly not helping the disks life span, it made an annoying noise and it caused small system hangs whenever the disk had to unpark it's heads to read some data. Under Linux one could use This turned out to be an interesting endeavour. The general problem of replacing the disk holding the rpool is common enough that the excellent ZFS troubleshooting guide has a section on doing this. The general plan of action is as follows:
This is all very sensible, and it all works as advertised. In my case there is, however, a last step not on the list above:
The reason for that is that the case I used only has one internal 2.5" hard disk drive slot. The new disk was prepared using an external USB-IDE converter module. This worked just fine, the BIOS is even able to boot from the USB disk. As long as the new disk remained attached to the USB converter everything was fine, even after the old (internal) disk was removed from the rpool. But putting the new disk into the case caused Solaris to roll over and die early in the boot process due to not finding it's rpool disk. The error message indicated that it was trying to read the pool from the external USB device (which no longer existed at this point). Investigation (and much swearing) turned up that this information was passed by GRUB to the Solaris kernel. Solaris uses a patched GRUB version which understands ZFS and has some string replacement magic built in. Every (non failsafe) boot entry contains a line similar to this: kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
The actual command line that is executed by GRUB thus looks something like this: kernel /platform/i86pc/kernel/$ISADIR/unix -B zfs-bootfs=rpool/328 \ bootpath="/pci@0,0/pci8086,2942@1c,1/pci-ide@0/ide@0/cmdk@0,0:a" The interesting part here is the Fixing this turns out to be easy: boot into failsafe mode with the new disk on it's final connector. This will search for rpools and BEs on the system and offer to mount one of them. Pick the right one, reboot. This is enough to get the current (and correct) device path embedded into the rpool. The next (non failsafe) boot will thus pick up the correct device path and allow the boot to continue. The morale of an afternoon thus spent in the innards of the Solaris boot process is thus: do not swap your rpool disk around. Saturday, December 12. 2009Creating a write only directory with SAMBA and ZFSOne of the intended uses of my OpenSolaris storage server was to serve as a "SAMBA":http://www.samba.org accessible data store. Part of that role was the wish to have an
So everyone can add files to the share, but removing them requires special privileges. It turns out that this is impossible to do with normal UNIX file system permissions, as for UNIX creating a file (which is a write operation on a directory) is much the same as deleting one (which is a write operation on a directory). Fortunately OpenSolaris supports a much more powerful file operation permission language in the form of NFSv4 permissions. It has been said that the NFSv4 permission system has been modeled after a smudged copy of the Windows NTFS permission system, and there is certainly merit to that claim, which is not a bad thing. The NTFS permission system is much more expressive than the standard UNIX system, as it has more actions (besides writing, reading and executing it also knows about deleting, for example), can support a large number of principals with different permissions and can actively deny an action (which is different from "not allowing"). h3. NFSv4 permissions The NFSv4 system knows about the following actions: |_. Action |_. Description for files |_. Description for directories | | read data | Read file contents | List directory contents | | write data | Write file contents (anywhere in the file) | Create new files | | execute | Execute file | Change into directory | | append | Append data to file | Create new directories | | delete | Delete the file | - | | delete child | - | Delete a file in the directory | | read/write attributes | Read/write basic attributes | (same as file) | | read/write xattrs | Read/write extended attributes | (same as file) | | read/write ACL | Read/write ACLs | (same as file) | | change owner | Change the owner | (same as file) | | sync | Use syncronous file access | - | NFSv4 also contains a mechanism to specify actions that apply to a file or directory, and actions that are inherited to child objects of a directory (i.e. files or subdirectories). This allows very fine grained control of file system access. Of special interest here are the bits about writing, appending and deleting files and folders. The ACLs are maintained in a list of entries, each entry mapping a username/action pair to a verdict (allow/deny). Each access is matched against each entry in turn, and the verdict is taken from the first entry to match. So the order of entries is important. Solaris' The permissions corresponding to the list of requirements stated above are as follows ( # ls -lVd /tank/share/incoming drwxrwxrwx+ 5 root root 6 Dec 12 16:49 /tank/share/incoming user:sun:-w--dD--------:fdi----:allow user:sun:-w--dD--------:-------:allow everyone@:-w--dD--------:f-i----:deny everyone@:----dD--------:-di----:deny everyone@:----dD--------:-------:deny everyone@:rwxp--a-R-c--s:-di----:allow everyone@:r-xp--a-R-c--s:f-i----:allow everyone@:rwxp--a-R-c--s:-------:allow # There are two kinds of entries in this list. Those with an This list can be read in three blocks: The first block consists of the first two lines. The first line specifies that the right to delete files ( The second block consists of lines 3 to 5 and contains only deny statements. They apply to The third block consists of the last three lines and restores some rights to non privileged users. Directories inherit the right to be read ( Let's see if that works out. $ id uid=60003(smbnobody) gid=60003(smbnobody) $ touch /tank/share/incoming/foo $ ls -V /tank/share/incoming/foo -r-xr-xr-x+ 1 smbnobody smbnobody 0 Dec 12 18:33 /tank/share/incoming/foo user:sun:-w--dD--------:------I:allow everyone@:-w--dD--------:------I:deny everyone@:r-xp--a-R-c--s:------I:allow The unprivileged user $ cat /etc/passwd > /tank/share/incoming/foo bash: /tank/share/incoming/foo: Permission denied $ cat /etc/passwd >> /tank/share/incoming/foo $ The user cannot overwrite the file (even though it is empty), but he can append to it. $ rm /tank/share/incoming/foo rm: /tank/share/incoming/foo: override protection 555 (yes/no)? y rm: /tank/share/incoming/foo not removed: Permission denied $ Deletion is also denied. Good. $ id uid=500(sun) gid=100(users) $ cat /etc/passwd > /tank/share/incoming/foo $ rm /tank/share/incoming/foo $ However, the privileged user h3. Samba configuration Samba also needs configuration to recognize and use the extended parmission system. The following is an excerpt from [incoming] path = /tank/share/incoming writable = yes guest ok = yes browseable = yes public = yes acl check permissions = False ea support = yes store dos attributes = no map readonly = no map archive = no map system = no map hidden = no vfs objects = zfsacl nfs4: mode = simple nfs4: acedup = dontcare This configures Samba to use extended ACLs using the ZFS (NFSv4) permission system. Wednesday, December 2. 2009Access problems with Apache server-statusSince I have twice now spent considerable time on debugging this: If you have configured an Apache This may seem obvious, but if the Apache is configured as a reverse proxy there may not be any files in the document root, because all content is created by the backend servers (or virtual handlers, like
(Page 1 of 1, totaling 4 entries)
|