Code Red and Nimda requests are annoying at best, and can complicate log processing. One option of dealing with these requests is to have Apache log the requests to a separate log file, which can be processed as needed. Additional uses for separate log files are explored.
The httpd.conf file will need to be manually edited to add the following features. For more information on the configuration outlined below, consult the Apache manual.
[robg adds: A previous hint includes a shell script to block Nimda and Code Red requests at the firewall level; this hint explains how to use Apache's custom logging features to log these activities in a separate log file without actually blocking the requests.]
Support for IPv6 was added to OS X with version 10.2. It is possible to access the IPv6BONE from any host connected to the Internet (provided it isn't behind a firewall blocking IP protocol number 41, IPv6 over IPv4).
This is possible thanks to "anycast 6to4 Relays". These are routers connected to both the Internet and the 6BONE. They advertise their presence by announcing the prefix 188.8.131.52 to other Internet routers. Computers with only IPv4 Internet connectivity can send IPv6 traffic to and from the 6BONE by defaulting to the 6to4 address for the 184.108.40.206 anycast prefix.
Substitute your IPv4 address in the following script, and then runit as root using sudo. Test connectivity with an IPv6 ping like the following:
[ross-Computer:~] ross% ping6 www.kame.net
PING6(56=40+8+8 bytes) 2002:9f86:c423::1 --> 3ffe:501:4819:2000:210:f3ff:fe03:4d0
16 bytes from 3ffe:501:4819:2000:210:f3ff:fe03:4d0, icmp_seq=0 hlim=58 time=349.581 ms
16 bytes from 3ffe:501:4819:2000:210:f3ff:fe03:4d0, icmp_seq=1 hlim=59 time=335.102 ms
16 bytes from 3ffe:501:4819:2000:210:f3ff:fe03:4d0, icmp_seq=2 hlim=59 time=337.292 ms
16 bytes from 3ffe:501:4819:2000:210:f3ff:fe03:4d0, icmp_seq=3 hlim=59 time=332.33 ms
--- apple.kame.net ping6 statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 332.330/338.576/349.581 ms
Not so much a hint as a gotcha. For reasons too dull to explain now, I have defined a web proxy on port 8080 for my "Automatic" network location. All was fine and dandy until I tried to access, via Safari, any sites locally hosted on my iBook while I was connected to the Internet via Airport. All I got was a Connection Refused page.
After a little head scratching, I realised that I needed to enter the loopback address and Rendezvous name of my iBook into the "Bypass proxy settings for these Hosts & Domains" section of the "Proxies" dialog (i.e. 127.0.0.1 and ibook.local for my set-up).
The Squid web proxy can be run on OS X as a proxy server for those with a network of web users wishing to speed access to static web content and eliminate duplicate downloads. The Squid Manager GUI makes it fairly easy to manage Squid, but currently doesn't provide a way to enable it at startup. Mac OS X provides a mechanism for this called SystemStarter, which looks in /Library -> StartupItems for particularly configured folders and files to tell it what to start up and how. After a bit of pain (partly due to leaving my firewall running during testing and hence tripping over it), I have created a functioning StartupItem for Squid.
A caveat: the owners, groups, and permissions for Squid's files and folders need to be set properly for Squid to run successfully (and safely) as a service. There's plenty of documentation accessible from the Squid website and elsewhere on the web about this. Suffice to say that even if Squid runs fine for you when invoked via Squid Manager or the command line, it may not run as a service if permissions are not appropriate.
To set up the startup item, download Squid.sit [2.4K download], expand it, then put the resulting folder into /Library -> StartupItems (not the folder of the same name under /System). Also, check the content to be sure it's not some Trojan or other nasty (you are sufficiently paranoid to consider such a check necessary, I hope). The files are all plain text.
Another caveat: the files I've created assume that the Squid executable is in the default location of /usr/local/squid/sbin/squid and the config file for it is in /usr/local/squid/etc/squid.conf.You'll need to set up squid.conf appropriately as well. This is so site-specific, I won't even begin to offer advice on that. Again, the Squid documentation is helpful, and I've found that it writes pretty useful error messages to the cache.log file if things are not quite right.
[robg adds: I have not tested this one; a previous hint explains how to use Squid to get around firewall authentication problems.]
My employer has a Microsoft VPN (PPTP) server and I finally got connected to it. The Internet Connection app allows you to access a VPN, but it has a couple of parameters that may cause problems, and it also might be useful to see the command line way to do it. I got the basic command line syntax by invoking Internet Connection, then looking at ps -axlww. Here's the command I use:
Where you replace 'domain', 'username', 'mypass', and the 'AAA.BBB.CCC.DDD', etc, IP addresses with the proper ones for your site.
What's the difference between this and Apple's version? First, I don't use 'usepeerdns' or 'defaultroute', which are more appropriate if the VPN connection will be your ONLY connection to the rest of the net. And I've extended the idle timeout to a half hour (instead of 10 minutes).
I had a lot of trouble figuring out how to use my brand-new Sony Ericsson T68i as a wireless modem with my AT&T GPRS Wireless Service. I had hoped that I could just "dial in" and use my thousands of minutes to get dialup service like any other modem connection. Unfortunately, AT&T wireless doesn't support this and it will disconnect almost immediately if you try. You must use their GPRS service and very few people know how to set it up correctly because it's so cutting edge.
Finally, I got it to work, but had to go to numerous sources, including several websites discussing related topics, my local Apple Store (which couldn't help either), and telephone calls with AT&T Wireless Services' Mobile Internet division (866-293-4634). Note that I was told they don't support Macs or Bluetooth. As a result of my difficulties, I wrote up a set of clear (I hope) instructions.
This is definitely one of the coolest things to do with a bluetooth phone and a real "showoff activity" for your PC friends.
I recently volunteered to update the website for my son's school. In order to beta test the site, I decided to use my .mac account to create a password protected web site. Addresses for .mac accounts use a URL similar to "http://homepage.mac.com/username". My username is formed as firstname_lastname, all in lower case. When I spoke to the school secretary to give her the URL and password, she asked if capitalization mattered. I told her that capitalization was important for the password, but that URLs are case insensitive. This is only partially true.
It appears that if you create a password protected site using .mac, capitalization of the username portion of the URL is important. When a user accesses a password protected .mac website they are presented with a web page that requests only the password. The username is parsed from the URL and is used for authentication. If the username portion of the URL is incorrectly capitalized, authentication will fail.
If someone accessing a password protected .mac website incorrectly capitalizes the username, the only way to get into the website is to purge the history list (this is the behavior in both IE and Safari) then provide the correctly capitalized URL.
[robg adds: I tested this with a password protected page on my mac.com site, and it's definitely true -- if my name is incorrectly capitalized, authentication fails...]
Several times, when going to a site that uses SSL encryption, IE (version 5.2.2) has given me an error message that said something like "Unable to establish a secure connection. There is a problem with the security certificate (issuer unknown). Any information you transmit will be readable by others."
These errors have come from sites that I trust and that IE on win2k gives me no trouble. The problem appears to be in OS X IE's not having all the root certificates it should, as was borne out by comments from one site that I contacted. They say they've bugged MS on this, to no avail.
Forget IE and use Safari. On the sites I've had trouble with on IE, Safari works great. No problems with the root certs.
Just say "continue" when asked if you want to continue, even though others can read your data. I suspect that IE still goes through a public key exchange, but just cannot guarantee the authenticity of the the server, and for legal reasons says "others can read" to play safe. That would be smarter than not exchanging a key at all, in which case everyone snooping on your connection could read it. While I cannot personally vouch that that's what IE does, it is according to the support at the one site I conversed with.
One last thought: Is it just coincidence that, in this sense, IE works fine on Windows but not OS X? Any conspiracy theories?