Felipe Alfaro Solana

Mac OS X X11 Server, called X11.app, is configured to open a new xterm on launch by default. This default behavior can be pretty annoying, but can be easily disabled.

In order to stop Mac OS X X11.app from launching a new and empty xterm when launched for the first time, one must install a customized .xinitrc file into $HOME.

During start, X11.app looks for $HOME/.xinitrc and, if no one is found, it executes /etc/X11/xinit/xinitrc. It’s the /etc/X11/xinit/xinitrc script the one that launches an empty xterm.

To stop X11.app from launching an empty xterm:

1. cp /etc/X11/xinit/xinitrc $HOME/.xinitrc
2. Edit $HOME/.xinitrc and remove the line that reads "xterm &"

This will prevent X11.app from starting useless client applications, like xterm, on launch.

It is possible to use several e-mail addresses for a single mail account in Mail.app. This can be very useful, for example, when using the new Aliases feature present in .Mac, or else using different addresses multiplexed on the same account (i.e. aaa@domain.com, bbb@domain.com).

To assign multiple e-mail addresses to a single account, simply select that account in the Accounts tab of the Preferences Pane and enter all the e-mail addresses separated by commas in the “Email Address” field. Once the changes are saved, you’ll be able to choose among all addresses when composing a new mail by selecting the desired one from the “Account” drop-down box.

LaunchServices contains a big, long list of all the Applications, and which ones accept documents of which type.

Basically, OS X LaunchServices is how an application is found to run when you double-click on a document. If the program is in /Applications, or you launch it at least once, then LaunchServices should detect it. LaunchServices contains a big, long list of all the Applications, and which ones accept documents of which type. So if you have an Application that is not “registering” correctly with LaunchServices how do you check it’s information? Try this in the Terminal:

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/
Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump

You should be able to copy and paste that, thanks to the backslash. But if you can’t, just make it one long line with no added spaces. This command will list all LaunchServices information. The output will look something like this:

B00001572 APPL/ddsk Thu Aug 5 21:25:59 2004 DiskImageMounter.app
-pad----hn---s--A---- v76.4.0 DiskImageMounter
Contents/Resources/diskcopy.icns com.apple.DiskImageMounter
Contents/MacOS/DiskImageMounter 12556, 1728655, Mach-O
V00000008 /System/Library/CoreServices/DiskImageMounter.app

....

The B entries list the programs’ basic info (in this case, for DiskImageMounter.app). The C entries below that show which file types the program will accept, with both a description and a list of extensions. So there you have it; everything your machine know about. But the question is … how do you clean out all the applications registered on unmounted DMG volumes which show at the end of the list?

While bundles are easy to uninstall (by dragging them to the Thrash), packages are difficult to uninstall since Mac OS X doesn’t have a native uninstall facility (like in GNU/Linux).

In Mac OS X applications can be packaged as bundles (a directory tree, like Mail.app/) or as packages using “Installer” or the command line “installer” tool.

While bundles are easy to uninstall (by dragging them to the Thrash), packages are difficult to uninstall since Mac OS X doesn’t have a native uninstall facility (like in GNU/Linux). Instead, the application package must supply an uninstaller. Some packages don’t provide an uninstaller, so how do we can uninstall them?

The answer lies in the “/Library/Receipts”, where every installed package creates a subdirectory with the same name as the package. For example, Fondu creates a receipt named “/Library/Receipts/Fondu-021223.pkg/”. Inside this receipt directory, we should be able to find a file with a “.bom” extension, which holds the list of files installed by the package. We can use the “lsbom” command-line tool to reveal what the contents of an installed package are. For example, to list the contents of the Fondu package:

# lsbom //Library/Receipts/Fondu-021223.pkg/Contents/Archive.bom
. 40755 501/20
./usr 40755 501/20
./usr/local 40755 501/20
./usr/local/bin 40755 501/20
./usr/local/bin/dfont2res 100755 501/20 22692 1924128762
./usr/local/bin/fondu 100755 501/20 80828 3987236398
./usr/local/bin/frombin 100755 501/20 26612 1252278923
./usr/local/bin/showfond 100755 501/20 48732 2572856512
./usr/local/bin/tobin 100755 501/20 34892 1234820618
./usr/local/bin/ufond 100755 501/20 96660 523810372
./usr/local/man 40755 501/20
./usr/local/man/man1 40755 501/20
./usr/local/man/man1/dfont2res.1 100644 501/20 599 1712045017
./usr/local/man/man1/fondu.1 100644 501/20 1677 2399414942
./usr/local/man/man1/frombin.1 100644 501/20 602 3676561646
./usr/local/man/man1/showfond.1 100644 501/20 568 2643007451
./usr/local/man/man1/tobin.1 100644 501/20 1315 3726043
./usr/local/man/man1/ufond.1 100644 501/20 1988 585312571

Using this list, we can manually remove the Fondu package by removing every listed entry. If it’s a file, it can be deleted, but if it’s a directory, we must be sure it’s empty and not being used by any other package.

The “smurf” attack, named after its exploit program, is an attack in the category of network-level attacks against hosts. A perpetrator sends a large amount of ICMP echo (ping) traffic at IP broadcast addresses (either subnet or not), all of it having a spoofed source address of a victiim.

If the routing device delivering traffic to those broadcast addresses performs the IP broadcast to layer 2 broadcast function noted below, most hosts on that IP network will take the ICMP echo request and reply to it with an echo reply each, multiplying (amplifying) the traffic by the number of hosts responding. On a multi-access broadcast network (i.e. Ethernet), there could potentially be hundreds of machines to reply to each packet.

There are two parties who are hurt by this attack:

• The intermediary (broadcast) devices, called amplifiers
• The spoofed address target, or the victim

The victim is the target of a large amount of traffic that the amplifiers generate, as a consequence of replying to the ICMP echo request received at the broadcast address.

Preventing Linux hosts from responding to ICMP echo requests targeted to the broadcast address

There is a “sysctl” knob which controls if the Linux kernel should ignore any received ICMP echo request packets whose destination is the broadcast address. This knob is:

net.ipv4.icmp_echo_ignore_broadcast

Setting it to 1 will make the kernel to silently drop any incoming ICMP echo request targeted at a broadcast address, either subnet (i.e. 192.168.0.255) or global (255.255.255.255). When set to 0, the host may respond to any received ICMP echo request packet targeted at a broadcast address.

Thus, the recommended value for this knob is 1.

An entry can be added to the file “/etc/sysctl.conf” with the following syntax:

net.ipv4.icmp_echo_ignore_broadcast=0|1

Preventing Mac OS X hosts from responding to ICMP echo requests targeted to the broadcast address

Since Mac OS X is a FreeBSD underneath, there exists a “sysctl” knob used to control whether Mac OS X should respond to ICMP echo requests targeted at the broadcast address. This knob is:

net.inet.icmp.bmcastecho

When set to 1 (the default value), the kernel may respond to ICMP echo requests targeted to the broadcast address. Setting it to 0 will prevent the kernel from responding to such packets.

Thus, the recommended value for this knob is 0.

An entry can be added to the file “/etc/sysctl.conf” (which could be an empty file or even exist) with the following syntax:

net.inet.icmp.bmcastecho=0|1

iBackup has problems backing up folders to iDisk if those folders’ icons have been customized.

BRIEF: It’s a problem caused by folders with customized icons.

DETAILED: Sometime ago, I customized the icons for the “Library” and “Documents” folders as I didn’t like the default ones – I took the icons from the wonderful World of Aqua set of icons. When you customize the icon of a folder, a zero-sized file named “Icon?” (or Icon^M when viewed from the command line) is created inside that folder.

It seems that iBackup doesn’t cope well with this kind of files, at least when backing up to the iDisk. When the folders being backed up have a customized icon (a file named Icon?), iBackup will complain with the following error message:

“/Users/falfaro//Icon” not found on iDisk. This file does not exist on the iDisk.

SOLUTION: Remove the offending “Icon?” file from the folder in question and then retry the operation.