Using a Bluetooth Phone for an Internet Connection

Some weeks ago I switched from a straight dial-up internet connection on my Mac (on a PowerPC) to a cellular phone link. Over the past many days, I’ve learned many things, good and bad.

The link starts with setting up the bluetooth link with the computer. For me, running MacOS X Tiger, this involved getting a USB-Bluetooth adapter and then configuring the Bluetooth preference pane (under Hardware in System Preferences).

Setting up the hardware and pairing the phone was actually the easy part: the preference pane runs the Bluetooth Setup Assistant, which takes you through the process of pairing a new phone step by step. You’ll have to make sure your phone is “discoverable”, that is, the phone responds to anyone who requests it. After that, your phone will be paired using a code, and your phone will be examined for its capabilities.

Once the phone is paired, it will be necessary to set it up for Internet connection. It can take some guessing (!) to get the right connection script; for me, it was the “Nokia 3G Packet RB 460″ (whatever that all means). This works with my Nokia 6265i and my CDMA 1xRTT connection.

The biggest hurdle of all was getting the phone number and password. The phone number (which seems to be rather generic for cellular internet) is #777. The username and password are carrier-specific; my carrier is U.S.Cellular, and they use phonenumber@uscc.net for name and password.

Once this is all done, you should be able to connect using the cellular phone over its Bluetooth connection.

However, that isn’t all. The connection is not much faster than a dial-up connection (though it is faster). In my case, if the call is dropped for various reasons, then the phone may no longer connect – and it turns out that it is mostly the phone which is at fault.

For example, one possibility is that the bluetooth connection will go through, but the modem will not respond to commands. Another possibility is that the modem will respond, but the dialing of the number will be ignored. Another possibility is that the bluetooth connection will “fail” (as reported by the phone and the computer) for whatever reason. All of these possibilities seem to be related to dropped connections.

Remember that there is a bluetooth (wireless) connection to the phone (which acts as a modem connected via a wireless serial link). The phone then dials (when requested) using its cellular technology. If the cell phone does not have reception, or otherwise cannot dial, then this will fail (mysteriously in most cases).

One particularly nasty case is if the phone runs out of battery and shuts down. This can result in the aforementioned failure to dial and the failure to respond to any modem commands at all – and often these errors will go back and forth! One time the modem will not respond, the next it will but won’t dial. After the phone shuts off, perhaps the best thing is to leave it off and recharge.

The recharging of this particular phone is fast when it is off – and probably is for other phones as well, or at least faster than when it is running. When the phone is connected to a data call via bluetooth, then placing it on the charger keeps it going.

Another thing to watch for is receiption. The phone will never give any errors relating to weak reception, but rather will just fail mysteriously.

I hope that my experiences can help you to avoid any of the difficulties I had. If you have any solutions for niggling problems or other’s difficulties, add them below….

Oh one little nugget for visiting: did you know you could get free computer-generated musical ringtones for free at WolframTones from Wolfram Research? Now you know….

Learning Something New

Every day, a system administrator may come across something new, or a way to apply some new knowledge. Don’t stop learning, and take whatever steps are necesary in order to learn whatever you can.

Don’t stop at knowing just enough to get by – what buttons to push, what commands to execute – aim to master something new. Dave Thomas (the writer of the Ruby “pick axe book”) suggests learning a new programming language every year.

Do you use Korn shell in your daily work. Master it! Learn the intricate details. Learn ways to be more efficient, to do things faster, to do things quicker. Learn the intimate details of awk scripting. Learn the many details of sed.

Are you bored with the everyday? Then stretch your mind and start in on something unusual – even unnecessary. Learn how to run the TECO text editor (EMACS was written in it!). Learn COBOL and use OpenCOBOL.

Learn something new and useful but unutilized – such as Lua or TCL.

Alternately – since we are all system administrators here – put a new server environment to work in your home network. Install Kerberos and the Andrew File System. Start working with the Berkeley amd automounter. Set up an IPv6 network.

What does all of this learning get us?

• Opportunities for improving speed of current operations
• Opportunities to improve implementation time (of scripts etc.)
• Faster debugging
• Knowledge ready for new business initiatives
• Stretches your mind into new directions
• Sharper mind throughout a lifetime

So what are you waiting for? Pick something to learn and stick to it – and do it just for you. Sooner or later, if you keep it up, your employer will notice.

A Single Point of Failure

Recently, the 365 Main colocation facility in San Francisco went down due to local power outages and related failures with their backup systems. The best detailed technical description was at Scobelizer (read the comments) and the best technical overview of the entire situation is at CNET News.com. Other reports can be found at:

DataCenter Knowledge

What with all of this happening, it has me thinking of single points of failure. To completely handle all disasters, there must be complete redundancy throughout the system – and there is no way to keep costs down while making a complete redundancy set up. From the description given at Scobelizer, there is a complete and sophisticated power backup system, but the multiple losses of power caused the backup system to stop providing power.

In the case of 365 Main, it sounds as if their backup power was not redundant – though one could spend a lot of money in trying to be completely and utterly redundant. Lets consider all of the parts that need to be redundant if complete redundancy was required:

• System software
• Applications
• System hardware, including power (power supplies)
• Data center power
• Data center air conditioning
• Backup power
• Data center location
• Backup tapes
• Backup system
• Notification system
• Notification “chain-of-command”

And certainly there are more. The possibility of failure will never be zero. It is almost foolish to guarantee 7 days a week, 365 days a year up time. Failures happen, and will affect us. Let’s consider some of the ways that 365 Main and its customers might have avoided their troubles.

First, 365 Main did not have differing backup power systems, from what has been said. The method of generating backup power remained the same throughout. A completely different backup power source, using different methods would in all likelyhood have prevented their power loss. No doubt it would have prohibitively expensive, however…

Alternately, the customers of 365 Main could have had secondary hosts elsewhere in a geographically widely dispersed cluster. If one host goes down (in San Francisco, say) then the hosts in Denver, New York City, and Chicago could keep going.

Having redundancy throughout can be expensive, but not having redundancy can also be expensive, as some major web sites found out recently.

Zombies

Zombies are processes that have terminated, but have not been able to return their ending status to any parent. A zombie does not occupy any resources except a single process table entry. There is no code in memory, no data, no file descriptors, no pipes, no ports – nothing.

This happens because the parent (the spawning process) did not handle the child’s return properly – that is, it did not handle the SIGCHLD (or SIGCLD) signal properly. When such a parent finishes, then the process becomes a child of the init process (process ID #1). It is then expected that /bin/init will reap the process (cull the return status) using a wait() call.

However, sometimes init will not reap zombies, or the parents remain running and never reap. What’s worse, this handling of process children varies from operating system to operating system, so proper handling is often not portable. Handling spawned processes requires proper handling of the SIGCHLD signal, with the proper wait() commands.

One recommendation is thus: institute a SIGCHLD handler which will continue to wait for processes (using wait()) until there are no more processes. The (almost) pseudocode for such a handler would be:

handleCHLD {
while (deadProcessesExist)
continue;
}

It may be possible to kill off a zombie by sending a SIGCHLD to the parent process, but again this is not portable and only works on some System V derived systems. To do this, execute the command

kill -17 ppid

This sends a SIGCHLD signal to the parent process, given the proper process id (ppid) to send it to.

Further resources:

Zombies(5) from System V manpages
UNIX FAQ Question 3.13: How do I get rid of zombie processes that persevere?
Delve into UNIX Process Creation

The wheel Group

The wheel group is, perhaps, not widely used today, or is seen as “archaic” and irrelevant. Nothing could be further from the truth.

The wheel group is a group which limits the number of people who are able to su to root. This usually consists of a group named “wheel” and a set of users that are permitted to use the utility ‘su’ in order to change to root.

Many systems, especially either commercial systems or Linux systems, come without wheel groups configured and implemented. At least one Linux distribution, comes with wheel groups preconfigured but not active. However, all or nearly all BSD based systems will come with the wheel group installed and set up.

However, at its simplest, a wheel group implementation requires no special set up. The basic set up, as it was in the beginning, was to do the following:

1. Create a “wheel” group in /etc/groups
2. Change the permissions of the “su” command so that only those in the “wheel” group may run it.

That’s all there is to it. Many su implementations, however, added internal support for the wheel group, perhaps with logs kept and a more informative refusal message explaining why su would not run (for those not in the wheel group).

Perhaps one reason that the wheel group is not widely used may have something to do with the GNU project. The GNU implementation of su has this in its info page:

Why GNU `su' does not support the `wheel' group
===============================================

   (This section is by Richard Stallman.)

   Sometimes a few of the users try to hold total power over all the
rest.  For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else.  (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)

   However, occasionally the rulers do tell someone.  Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest.  The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.

   I'm on the side of the masses, not that of the rulers.  If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.

Is it any wonder that GNU/Linux systems don’t enable the wheel group by default? FreeBSD, however, does use the wheel group by default – as does OpenBSD and NetBSD.

Using Mac OS X as a network gateway

I have been using my Mac Mini running Mac OS X 10.4 as my network gateway, and it isn’t all that difficult.  The most difficult part (currently) is that the settings must continually be reset (as the system will stop providing gateway services after a period of disuse apparently).

The steps are quite simple:

• Open the System Preferences application.
• Type into the quick find box: “Internet Sharing” and press enter
• At the panel that opens up….
• At “Share connection using:” select the proper connection to the Internet that you want to share.
• At “To computers on:” select the location that describes the computers that you want to share your Internet connection with.
• Finally, click on “Start” (towards the top) and click “Ok” on the “Are you sure?” dialog that comes up.

Your connection is now being shared amongst all of your systems.  You still have to configure them to use the gateway, though this could be done using DHCP.

From time to time, the Mac will turn off “Internet Sharing”.  In most cases, you will just have to go back to the “Internet Sharing” window and click on “Start” again to restart things.  Be aware that if the “Internet Sharing” panel has been open all along, it will not update dynamically – selecting another tab in that panel and reselecting the “Internet” tab will update the panel correctly.

Foreign Languages: A BARcamp Experience

One experience at BARcamp Chicago stood out for me – it was unusual for me. I’m not one to take part in multiuser dungeons (MUDs), or anything of the sort. However, one person who was ran into a person who spoke no English, but spoke French.

Now I speak passable French, and can type, so I become a sort of interpreter. Thus, here I was conversing with (it turned out) a Belgian and helping the two gameplayers to converse.

Learning a foreign language can be a benefit, and it can help you professionally as well. One notable time was when I helped my employer (a bank) to understand a French check that was returned for non-sufficent funds (in English, NSF).

There are a lot of foreign language technical resources as well – don’t forget to visit them and try to understand them if you have the knowledge. If you don’t, then use services like Babelfish to translate them.

If you know a foreign language, keep it up by listening to it often and reading foreign language news. You can start to lose some of your proficiency if you don’t. You can listen to foreign language podcasts, or read foreign language newspapers online, or attempt to read or edit online foreign language wiki entries – or even read foreign language corporate sites.

Here are some possible resources (using French, Spanish, and Russian as examples) – search Google for others.

• French
  • LeMonde – A French newspaper
  • Microsoft France
  • French Wikipedia
• Spanish
  • Spanish Wikipedia
  • Microsoft Spain
  • El Pais – a premier Spanish newspaper
• Russian
  • Pravda – a Russian newspaper
  • Microsoft Russia
  • Russian Wikipedia

Many sites can be found just by using the appropriate domain: the Esperanto Wikipedia would be at
http://eo.wikipedia.org
, Apple Germany at
http://www.apple.de
, and Microsoft Germany at
http://www.microsoft.de
. You could even use Google France (http://www.google.fr) or Amazon France (http://www.amazon.fr) to search for more French materials, for example.

Slide Presentations

Any system administrator will have to make a presentation at one time or another – or should at least know how to. There are some very good sources for ideas on how to make slide presentations (sometimes called PowerPoint presentations).

First off, you don’t have to use PowerPoint – this should be obvious but isn’t to a lot of people. Macintosh users of recent vintage can use Keynote; also available for Macintosh, Windows, and Linux is OpenOffice (or its Macintosh-specific spinoff, NeoOffice). Note, too, that you don’t need to use slides at all. Use them only if they add something to your presentation.

Secondly, when creating a slide presentation, remember this rule: don’t read the slides. While this is a rule of presentation, it is important because this can be found directly in how the slides are created. Think of it this way: there should be things you say that are not in the slide.

Thirdly, be creative. This can be hard – and overdone. As a very interesting and dynamic presentation, consider this presentation given by Dick Hardt from the O’Reilly OSCON 2005.

Here are some excellent resources about presentations:

• Presentation Zen – an ongoing blog on presentations
• 12 Tips for Creating Better Presentations from Microsoft
• From the people over at the KnowHR blog comes The Best Presentations Ever (a Squidoo “lens”) – which in some ways mimics their Top 10 Best Presentations – but it also leads to The Top 10 Presentations – the Reader’s Choice

Who owns your remote documents?

Mark Rasch, in his latest column for SecurityFocus, Don’t Be Evil, discusses quite eloquently the legal dangers of storing documents on remote servers.

With his usual clarity, he discusses the risks and explains why sensitive documents are better off being kept off such servers.

This doesn’t just affect Google Docs but also affects any other Web 2.0 site that offers remote storage, such as Thinkfree Office and Box.Net (all of which I consider to be splendid offerings).

The problem is that any documents stored on Google’s servers (for example) can be subject to discovery in a legal process, and Google likely can be subpoenaed for your documents even without your knowledge.