Skip to main content

sharemgr.exe not found

I feel kinda stupid even asking this, having done this for years now, but: how do you create NFS shares on a Solaris 10 system? /etc/exports is obsolete, but so is dfstab(4), apparently:

      Do not modify this file directly. This file is reconstructed and only 
      maintained  for backwards compatibility. Configuration lines could
      be lost. Use the sharemgr(1M) command for all share management.
However, sharemgr(1m) does not seem to exist on this Solaris10 box. Well, sharemgr has been introduced in late 2006 (in response to Bug#6281048) but this nifty tool hasn't made it to Solaris10 yet.

So, for now we're stuck with:
  • editing /etc/dfs/dfstab or
  • using zfs set sharenfs, for ZFS filesystems.

  • There are nice articles from Doug McCallum on this topic:
  • Share properties under sharemgr
  • sharemgr and ZFS
  • ggrep --devices=skip

    Every now and then I'd like to (recursively) search for patterns in a directory tree. Since Solaris' grep(1) does not understand -r, I used SUNWggrep. But grep'ing through e.g. /etc never seems to come to an end, and truss(1) knows why:

    $ /usr/sfw/bin/ggrep --version | head -1
    grep (GNU grep) 2.5
    $ truss -elfda /usr/sfw/bin/ggrep -D skip -r foo /etc
    [...] 
    8341/1:          0.0448 open64("/etc/cron.d/FIFO", O_RDONLY)            = 3
    8341/1:          0.0454 fstat64(3, 0xFFBFFA78)                          = 0
    8341/1:         read(3, 0x00044000, 32768)      (sleeping...)
    
    Well, I won't comment on the fact that we have devices in /etc at all, but I explicitly told grep to skip devices. Apparently this option is just being ignored. Using the latest GNU/grep CVS checkout does help and the changelog does indeed mention a fix for the --devices option.

    Oh, of course: this could be done with find too, but GNU/grep is so much easier than:
    $ find /etc -type f -exec grep foo '{}' +
    
    Hint: add "-D skip" to your GREP_OPTIONS environment variable, that way it's passed to GNU/grep automatically.

    Update: a careful reader noticed that I confused SUNWggrep and SMCgrep - I did indeed and corrected it, finally. Thanks for the hint! For the record, the current version of SMCgrep does NOT have this problem, it's all good! :-)

    binding cherokee to a single network address

    Well, this is my first attempt with Cherokee and I thought server!listen was a valid configuration key. However, the latest GIT checkout gave:

    $ /opt/cherokee/sbin/cherokee -C ./cherokee.conf 
    ERROR: Server parser: Unknown key "listen"
    Couldn't read the config file: ./cherokee.conf
    
    This has been reported already and is said to be fixed with changeset 2766, so why is this still happening?

    Update: As an observing reader pointed out, the correct key is named server!bind!1!interface now. The changelog is rather quiet about this, but searching in the commits reveals that this change has been made last year already, though the documentation still mentions server!listen.

    Fedora: which which

    Oh, come on, Fedora 11, a base install with no X11 contains almost 1000 packages but you don't have "which"? Better yet, you have an extra package for this? Wow:

    $ yum info which
    [...]
    Name       : which
    Arch       : i586
    Version    : 2.19
    Release    : 4.fc11
    Size       : 40 k
    Summary    : Displays where a particular program in your path is located
    
    Something like "fedorautils" might help, hm?
    $ dpkg -S `which which`
    debianutils: /usr/bin/which
    
    Oh, and while we're at it: here's how to get httpd running on a different port:
    # service httpd start
    Starting httpd: (13)Permission denied: make_sock:
    could not bind to address 192.168.10.104:1080
    no listening sockets available, shutting down
    Unable to open logs                                    [FAILED]
    
    # tail /var/log/audit/audit.log
    [...]
    type=AVC msg=audit(1242447992.170:51): avc:  denied  { name_bind } for  pid=6144 \
    comm="httpd" src=1080 scontext=unconfined_u:system_r:httpd_t:s0 \
    tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
    
    # /usr/sbin/semanage port -a -t http_port_t -p tcp 1080
    # service httpd start
    Starting httpd:                                          [  OK  ]
    
    A detailled explanation can be found in the Fedora SELinux User Guide.
    Note: semanage comes with the policycoreutils-python package.

    Rainforest Schmainforest

    After stumbling over yet another celebritiy to speak out about the (dying of our) precious rainforests, I just couldn't help myself and wanted to see if the numbers add up. I'm talking about the rate at which the rainforests are destroyed, as they rank from "the size of a football" field every second or every four seconds.

    A standard football pitch is about 7000 sqm in size. The size of the rainforest was much harder to come by, the number I have now is 2.6 million square miles or 6.73*10^12 sqm. Well, by that rate we should be out of trees in 122 years resp. 30 years with the more scarier number. Still, wouldn't that be just enough time to plant new trees as they are cutting them down? Then again, I don't know jack about envrionmental issues, but this play on numbers got me curious :-\

    chmod octal form of sgid/suid removal fails

    The was a disturbance in the force today:

    $ mkdir dir
    $ touch file
    $ chmod +s dir file
    $ ls -l
    drwsr-sr-x 2 root root 4096 Apr 30 11:54 dir
    -rwSr-Sr-- 1 root root    0 Apr 30 11:54 file
    
    $ chmod 0750 dir
    $ chmod 0640 file
    $ ls -l
    drwsr-s--- 2 root root 4096 Apr 30 11:54 dir
    -rw-r----- 1 root root    0 Apr 30 11:54 file
    
    Yes, this is even documented behaviour and conforms to POSIX as well - still, I find it far from being intuitive. There's a quite an interesting posting at the bug-coreutils list, stating:
    > This topic came up when I first added that feature, and originally I
    > agreed with you, but others did not and their arguments were
    > persuasive.  The counterargument is that it's strange if a leading
    > zero changes the semantics of a number, as this is not what many
    > people expect.
    
    ...mentioning an earlier discussion on the same list. Oh well...

    mod_mime_magic: invalid type 0 in mconvert()

    I remember having these messages in my Apache logs before:

    mod_mime_magic: type search/400\t\\\\section\ttext/x-tex invalid
    mod_mime_magic: type search/400\t\\\\setlength\ttext/x-tex invalid
    [...]
    mod_mime_magic: invalid type 0 in mconvert().
    
    ....and I even remember setting up a workaround for this one. Now, years later this issue comes up again. Here's a rather ugly, semi-automatic attempt to remediate this (cosmetic) error:
    $ awk '/mod_mime_magic:.*invalid$/ {print $9}' /var/log/apache2/error.log | \
       sort -u | \
       sed -e 's/search\/400.*\\\\/search\/400.*/;s/^regex.*tory\\t/regex.*/;\
       s/\//./g'  > /tmp/1
    $ mkdir /usr/local/share/file/
    $ cp /usr/share/file/magic.mime /usr/local/share/file/
    $ for i in `cat /tmp/1`; do
         sed "s/^.*$i/# &/" -i /usr/local/share/file/magic.mime
      done
    
    Now we can point MIMEMagicFile in mime_magic.conf to the new magic file and the errors should go away. Of course, fixing libmagic1 would be cool too :-)

    HFS+

    I just noticed that I could not chown files on this newly created HFS+ disk. Using diskutil, I could only see a few noteworthy differences:

    $ diskutil info /
    [...]
       File System:       Journaled HFS+
                          Journal size 8192 k at offset 0xe2000
       Owners:            Enabled
       Partition Type:    Apple_HFS
       Protocol:          ATA
    
    $ diskutil info /Volumes/disk4
    [...]
       File System:       Journaled HFS+
                          Journal size 81920 k at offset 0x1d1e000
       Owners:            Disabled
       Partition Type:    Apple_HFS
       Protocol:          Disk Image
    
    As someone else suggested, I was able to use vsdbutil to enable ownerships/permissions again:
    $ mount | grep /Volumes/disk4
    /dev/disk4 on /Volumes/disk4 (hfs, local, nodev, nosuid, journaled, noowners)
    
    $ vsdbutil -a /Volumes/disk4
    $ vsdbutil -c /Volumes/disk4
    Permissions on '/Volumes/disk4' are enabled.
    
    $ mount | grep /Volumes/disk4
    /dev/disk4 on /Volumes/disk4 (hfs, local, nodev, nosuid, journaled)
    

    raw disk access in VirtualBox

    With VirtualBox being the only open source virtualization suite for MacOS X at the moment, I'm running it from time to time to test new stuff. Currently there's a two disk storage box standing at my desk and I wanted to attach both disks to a VirtalBox Guest OS. Although documented in the manual and in the blogosphere, I found it hard to find the (few) commands needed to do this:

    darwin$ diskutil list
    [...]
    /dev/disk3
       #:                  TYPE NAME              SIZE       IDENTIFIER
       0:      GUID_partition_scheme             *931.5 Gi   disk3
       1:       Microsoft Basic Data              931.5 Gi   disk3s1
    
    darwin$ VBoxManage internalcommands createrawvmdk \
                -filename disk0.vmdk -rawdisk /dev/disk3 -register
    
    The resulting .vmdk file will only hold metadata but not contain any actual data - exactly what we want :-)

    Oh, and while we're at it: disk performance sucks in MacOS X. IMHO, sequential read/write bandwidth from/to the raw device should only be limited by its HBA respectively the device attached to it. Well, this SATA disk (WD10EACS) is specified with 3Gb/s or ~375 MB/s and is attached via Firewire 800 which in turn should be able to deliver speeds up to 100MB/s. But under MacOS 10.5 (fully patched), dd only scores ~16MB/s. It's good to know though that the VirtualBox Guest OS (Linux 2.6) with raw access to this disk is receiving these 16MB/s as well, so no overhead here. Accessing the same disk on the same box (iMac, MB323LL/A) natively under Linux 2.6 gives us ~66MB/s - a far more reasonable number.

    Resizing a VMware disk for WinXP

    This WindowsXP installation in VMware Server virtual machine was low on diskspace. So I looked at vmware-vdiskmanager which comes with VMware Server to resize the boot disk. The fact that my VMware disk was split into 2 GB slices (sigh) did not matter at all:

    # ls -lgoh *vmdk
    -rw------- 1 1.9G 2009-04-22 20:25 winxp-s001.vmdk
    -rw------- 1 2.0G 2009-04-22 20:25 winxp-s002.vmdk
    -rw------- 1 706M 2009-04-22 20:25 winxp-s003.vmdk
    -rw------- 1  457 2009-04-22 20:11 winxp.vmdk
    
    # vmware-vdiskmanager -x 6GB winxp.vmdk
    Using log file /tmp/vmware-root/vdiskmanager.log
    The old geometry C/H/S of the disk is: 9752/16/63
    The new geometry C/H/S of the disk is: 12483/16/63
    Disk expansion completed successfully.
    
    # ls -lgoh *vmdk
    -rw------- 1 1.9G 2009-04-22 20:25 winxp-s001.vmdk
    -rw------- 1 2.0G 2009-04-22 20:25 winxp-s002.vmdk
    -rw------- 1 706M 2009-04-22 20:25 winxp-s003.vmdk
    -rw------- 1 415M 2009-04-22 20:25 winxp-s004.vmdk
    -rw------- 1  457 2009-04-22 20:11 winxp.vmdk
    
    I guess these are sparse images, growing dynamically in size. Now, we still have to tell WinXP that its boot disk has been resized. As it is the boot disk and we cannot use WinXP magic, I've decided to go with the GParted LiveCD. However, booting failed with strange SCSI errors. Chaning the VMware SCSI driver helped: simply set/add scsi0.virtualDev = "lsilogic" to your .vmx file - now GParted was booting and I was able to resize the parition. After doing that I found a resize-windows.txt on the LiveCD, stating that WinXP may have a problem when partition sizes change. Well, too late for that no as I already resized the disk. Luckily, WinXP was booting (after a chkdsk run has been forced), presenting me with a 6GB C: drive - nice :)