Last night I was trying to contact Verizon to report an abuse case:
$ whois 108.1.192.xxx | egrep 'Name:|Email' OrgName: Verizon Internet Services Inc. NetName: VIS-BLOCK OrgAbuseName: VIS Abuse OrgAbuseEmail: email@example.com OrgTechName: Verizon Internet Services OrgTechEmail: IPNMC@gnilink.netToday, I see that the
OrgAbuseEmailhas been changed to
firstname.lastname@example.org when Cc'ing
IPNMC@gnilink.netmy MTA returns:
> The message has not yet been delivered to the following addresses: >Oh well....
> host mail.gnilink.net[188.8.131.52]: > connection to mail exchanger failed with timeout > host mail.gnilink.net[184.108.40.206]: > connection to mail exchanger failed with timeout
$ date Thu Mar 11 04:46:26 CET 2010 $ whois 108.1.192.xxx | grep OrgAbuseEmail OrgAbuseEmail: email@example.com...wtf? Are they changing their abuse contact every day now?
Wow, another entry covering some Windows oddity. One might think this OS is full of oddities :-) This time I tried to rename c:\program files because I wanted to mount another disk to c:\program files. Sure, lots of programs might be running from c:\program files, but when I stop all these programs, WindowsXP should still be able to boot and even start RDP to let me login, right? And so it did, with a few preparations made:
C:\Program Files cannot just be renamed - WindowsXP won't let you, it's some kind of magic special folde^Wdirectory. We'll use regedit to modify two keys:
Set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir to something else, e.g. "C:\Program Files2" While this gets exported as "%ProgramFiles%" via "ProgramFilesPath", we have to edit another key:
Set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CommonFilesDir to something else, e.g. "C:\Program Files2\Common Files". We have to reboot to apply these changes, of course :-)
- After the reboot, we should be able to rename c:\program files to something else. You might notice that our interim %ProgramFiles% directory got filled with a few directories - just ignore them. With our original c:\program files our of the way, we create an empty c:\program files, where we can now mount the other disk. Once this is done, we can start moving the our original c:\program files content (that we just moved out of the way) into our new c:\program files directory. While it's moving, we can set the registry keys we changed (see above) back to its original values.
This one time I have to deal with rpm packages and this happens:
$ rpm2cpio file.rpm | cpio -id cpio: Malformed number....and only garbage is being passed to cpio. Since RPM now comes with XZ/LZMA compression support, we have to prepare this for
rpm2cpiowill be fixed:
$ rpm2cpio file.rpm | lzma -d | cpio -id 7090 blocks
ACLsACLs are extending the traditional permission model with a more fine-grained one.
- - getfacl, setfacl - filesystem independen access control list manipulation
- - chacl - an IRIX-compatibility command
$ chacl u::rw-,g::r--,o::r--,u:dummy:--x,m::r-x file.txt $ chacl -l file.txt file.txt [u::rw-,u:dummy:--x,g::r--,m::r-x,o::r--] $ su -c "cat ./file.txt" dummy cat: ./file.txt: Permission denied $ setfacl -m u::rw-,g::---,o::---,u:dummy:r--,m::r-x file.txt $ getfacl file.txt # file: file.txt # owner: root # group: root user::rw- user:dummy:r-- group::--- mask::r-x other::---
EAsExtended attributes are arbitrary name/value pairs which are associated with files or directories.
- setfattr, getfattr - filesystem independent extended attribute manipulation
- attr - aimed specifically at users of the XFS filesystem
$ attr -q -s foo -V 42 file.txt $ attr -g foo file.txt Attribute "foo" had a 3 byte value for file.txt: 42 $ setfattr -n user.bar -v 23 file.txt $ getfattr -n user.bar file.txt # file: file.txt user.bar="23"
file attributesThese "file attributes" look like they were meant to be supported by the ext2/3/4 filesystems only. However, Btrfs, JFS and XFS support them as well, ReiserFS and Reiser4 do not. In fact, I haven't found a mount option for Reiser4 yet to support ACLs and EAs either :-\
- lsattr, chattr - list, change file attributes
# chattr +i file.txt # lsattr file.txt ----i-------------- file.txt # rm -f file.txt rm: cannot remove `file.txt': Operation not permitted
I've received an email with one of those winmail.dat files attached, surprisingly these are still around. And there are lots of articles out there dealing with those attachments. Luckily there are also free TNEF *) parsers out there:
*) sounds like Tinnef, right? :)
For some time now I'm running MacOS X 10.6.2 with a 64-bit kernel and MacFUSE installed. However, after one of the last updates this setup stopped working - well, it shouldn't have worked anyway. Which is a pity, because now the TrueCrypt layer on top of MacFUSE doesn't work, which means ZFS cannot access its volume.
So, what now? Hacking MacFUSE would be the Right Thing to do, something I won't be able to deliver. So I went on to set up a much more fancy installation:
- install VirtualBox and attach the disk as a raw blockdevice
- within VirtualBox, install TrueCrypt and zfs-fuse
- once the VM has access to data, export it via Samba, so that the host machine can access it
We start by registering our MacOS data partition to VirtualBox. We're setting the disk immutable for now as we don't want to let our guest VM to make any changes to it. And we're also
chmod'ingthe disk to
0644, so that we're able to read it (and thus use it in Virtualbox). Mode
0640and a dedicated group would be more elegant, yes.
$ sudo VBoxManage internalcommands createrawvmdk -filename disk02-raw.vmdk \ -rawdisk /dev/disk0s5 -register $ VBoxManage modifyhd -type immutable disk02-raw.vmdk $ sudo chmod 0644 /dev/disk0s5We're using a Debian/testing (amd64) as a guest VM and we'll compile TrueCrypt (with wxWidgets as a dependency):
$ apt-get install libfuse-dev fuse-utils dmsetup pkg-config samba git-core scons\ libaio-dev libattr1-dev libacl1-dev libz-dev libz-dev libfuse-dev libssl-dev bzip2 $ wget http://prdownloads.sourceforge.net/wxwindows/wxWidgets-2.8.10.tar.bz2 \ -O - | tar -C /usr/local/src -xjf - $ cd /usr/local/src/wxWidgets-2.8.10 $ ./configure --prefix=/opt/wxWidgets && make && make install $ mkdir /usr/local/include/pkcs11 $ cd /usr/local/include/pkcs11 $ for i in pkcs11 pkcs11f.h pkcs11t.h; do wget ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/$i; done $ cd /usr/local/src/truecrypt-6.3a-source $ make NOGUI=1 WX_ROOT=/usr/local/src/wxWidgets-2.8.10 wxbuild $ PKCS11_INC=/usr/local/include/pkcs11 make NOGUI=1 WXSTATIC=1 $ mv Main/truecrypt /usr/local/sbin/Now we should be able to access our Truecryt volume:
$ truecrypt --text --filesystem=none /dev/hdc $ file -s /dev/mapper/truecrypt1 /dev/mapper/truecrypt1: Macintosh HFS Extended version [...]We can set up ZFS now:
$ git clone http://rainemu.swishparty.co.uk/git/zfs $ cd zfs/src && scons && scons install install_dir=/opt/zfs-fuse-rainemu $ export PATH=$PATH:/opt/zfs-fuse-rainemu $ zfs-fuse --pidfile /var/run/zfs-fuse.pid $ zpool import -d /dev/mapper -a -f $ zfs list NAME USED AVAIL REFER MOUNTPOINT tank0 135G 16.4G 135G /tank0Now we will be able to export
/tank0via Samba (or NFS, if needed) and can access it from our host machine as well. While surely not as speedy as local HFS+ (although I haven't actually measured yet), it's enough for watching movies or storing pictures. And apparently ZFS on Linux is much more stable and tested than on MacOS X. Well, to be honest, with this setup I could now even replace Truecrypt with dm-crypt and zfs with a stable filesystem, but that wouldn't be so much fun, eh? :-)
Today I found out that I have 3 leftover realmedia files in my archive. Sure, VLC can play this, but why not just converting them to something more useful? I haven't used mplayer in a while and I still did not find a way to redirect its output to stdout (no,
file=/dev/stdout did not work either). Using a FIFO was the way to go here:
$ mkfifo foo $ oggenc -q 6 foo -o file.ogg & $ mplayer file.rm -vc null -vo null -ao pcm:fast:file=$HOME/foo