Why T-Mobile picture messages are resized

Found an explanation for why TMobile messes with your picture messages:



http://www.howardforums.com/showthread.php?t=1064299&highlight=prepaid



So the problem is that T-Mobile is doing this intentionally in their MMS gateway. There are a couple of hacks to get around this, but they are non-trivial.



There's a slight difference between MMS (multimedia phone messages) and emails, which is why sending a picture as an "email" gives different results.

Cell Tower Mapping

I ran across this about six months ago, forgot where.

http://www.cellreception.com/towers/

Also has an area to post notes on cell phone dead spots.I've also noticed that many carriers are improving their onlinecoverage maps, but these tend to show "signal strength" by broad areaswithout explicitly depicting the location of towers...

Train as gothic atrocity? uh...

http://cowperthwait.livejournal.com/85239.html

Avowed Kink

Alarm Beacon for USB

I'm not aware of anything supported under OpenBSD,but this article could be a good start towards such a project:

http://www.linuxjournal.com/article/7353

(Yes, I know the article is about Linux. But the $59 USB beaconthey used in the article is platform-agnostic.)

More on the Apple PAC bug

Apple has this as case # 49365331.



Apple *still* doesn't realize the impact of this problem. I had to go througha group at work that has a megabuck support contract (hundreds of G5s),just to get a case number assigned.



The Proxy Automatic Configuration URL feature, as implemented in Safari, is broken. Instead of just making one HTTP request for the PAC file at the start of a session, Safari 2.0(412) makes a HTTP request to the PAC server once for each *object* requested -- for each HTTP request out to the Internet,a corresponding request is made to a local HTTP server, for the PAC file.I've seen individual workstations making PAC request at rates as highas 57 GETs/second, totalling over ten thousand hits in a day from a single Tiger workstation.



For comparison, the average MS-Windows client hits the PAC URL a mere 7 times per day. Normally a web browser will retrieve a fresh copy of PAC when first launched,and then cache this copy, refreshing the contents either based on the Expires header or using an internal refresh timeout (Under MSIE, the refresh time can be set using the IEAK).



When using a local PAC file (a file::/localhost/... URL), the network problems are avoided, but browser performance is poor, with sporadic broken images and general slowness in loading pages.



In MacOS Panther and Tiger, the option to configure proxy settings is under System Preferences/Network/Proxies. This menu gives the user the option to set the "PAC File URL", but no option for how/whether this file is cached and refreshed. Also, Safari does not respect Expires header sent with the PAC file.For each object accessed, Safari makes a new TCP connection to the PAC server (specifying "Connection: close") and sends a HTTP/1.0 request.



Workarounds:

Installing 10.4.1 does not resolve this issue.

Switching to Firefox eliminates this problem. Firefox will only download the PAC file at session start, or when the user manually chooses to reload it.



(P.S. A description of this problem was sent one week ago to the official "product-security@apple.com" address. Further assistance in bringing this issue to the attention of the Safari development team is appreciated.)



(P.P.S. I must give credit to Isaac Claymore for independently identifying the problem about a week before I first noticed it.)

Problems using MacOSXProxyAutoconfig under Tiger

Tiger introduces a serious problem with proxy.pac, no fix is availablefrom Apple.

There is a serious flaw with using aproxy.pac URL for Safari 2.0 on Tiger (MacOS 10.4.1). Specifically, Safari loads the PAC file and parses it correctly forthe first HTTP request, and then repeats the process for each HTTP request it makes. So each new Tiger workstation vastly increases theload on the server hosting your PAC file.

So if a user visits http://www.cnn.com/ which contains 21 unique web objects,Safari will generate 21 additional requests for the PAC. This bug is easy to independently confirm by checking the access log on the server hosting the PAC file. I figured this out only after the PAC server crashed :)

dc0: failed to force tx and rx to idle state

Sunfire V100 running OpenBSD 3.7 Sparc64 freshly installed offvia the official CD, is reporting "dc0: failed to force tx and rx toidle state".

Is this just cosmetic, or an actual problem?

Looking at the source code for the dc drive, this seems to be related tosetting speed and duplex (I lock the interfaces to 100/full).

I have an identical machine running 3.6, does not show this message,only the machines upgraded to 3.7 give this warning.

DNS monitor

Had a little incident today, so I ended up writing this.

Uses 'nslookup' because I actually wanted some of the nslookup side-effects;for example, it's difficult to get 'host' to "show it's work" and yetalso producethe same output in the same order each time (so the 'diff' will work correctly). Crude, yet effective.

Hopefully It'll just run quietly for years, never kicking off emails from cron,but at least now I won't be blindsided when somebody decides that simplybecause you can't ping something, it's okay to delete the host from DNS ;)

$ cat  $HOME/bin/dns-validate.pl



#! /usr/bin/perl



#



# No authorship, no copyright, no support.



# KK2005



#



#



$nslookup="/usr/sbin/nslookup";







$dir=$ENV{'HOME'}."/public_html/dns/";







$oldfile=$dir."status.then";



$outfile=$dir."status.now";







@ns= (  "127.0.0.1","207.227.240.1",



      );



#



#



#



die "Missing nslookup $nslookup $!"  unless(-x $nslookup);







chdir($dir)  die $!;



rename($outfile,$oldfile);







system("co -q -l $outfile");



open(OUT,">$outfile")  die $!;







while() {



      next if(m/^#/);



      chomp;



      print OUT "#" x 64, "\n";



      print OUT "#\n# ",$_,"#\n\n";







      foreach $server (sort(@ns)) {



              print OUT "\n # Server $server\n";



              print OUT `nslookup $_ $server`;



              print OUT "\n";



              }



      print OUT "### End $_ $nameserver###\n";



      }



print OUT "\n###\n# End nslookup\n#\n";











print OUT "\n# Contents of /etc/resolv.conf\n",`cat /etc/resolv.conf`,"\n";



print OUT "###EOF###\n";







close(OUT);



chmod(0644,$outfile);







system("ci", "-u", "-q", "-m$0", $outfile);



system("diff", "-w", "-c", "-T", $oldfile, $outfile);



exit($?);











__DATA__



#



#



# Enter your hostnames here, one per line.



# Comment lines must have a '#' as the very first character



#



# Example entries below, I recommend removing these.



#



127.0.0.1



example.com



###EOF###

Strange hardware errors? Consider a PROM Firmware upgrade

Every so often we run into a machine, physically identical to other boxes successfully converted, that fails in weird ways -- network and drive controllers not found, sporadic failure to recognize drives, etc.

Sometimes the problem turns out to be an actual hardware problem,
other times the root cause is the firmware version, either OBP
(OpenBoot PROM) or (less commonly) POST. The Sparc64 project page
hints at such issues, but does not go into details.

Sun provides a "Standalone PROM Update Utility" on CDROM, as well as
documentation on upgrading firmware:
http://sunsolve.sun.com/data/802/802-3233/pdf/802-3233-25.pdf

It is technically possible to update the PROM from a netboot server.
If you don't already have a netboot server, an alternative (suggested by Mike Scher) for systems without a CDROM drive is to keep a bootable SCA drive, containing a 32-bit Solaris and the latest prom update utility in the root partition.

OpenBSD Sparc64 on Sunfire V120

OpenBSD works amazingly well on "our" new SunFire V100 hardware.

With my pre-existing netboot buildout, doing a network installation on the SunFire was quick and easy -- faster than the Solaris network installation, if not quite as self-completing as my "fire and forget" firewall build boot :)

There are a number of security enhancements inherent in OpenBSD by which we can justify this admittedly unusual choice of operating system for DNS and other specialized applications where security is more important than "normalization"

Kevin


(P.S. FreeBSD 5.0 for Sparc64 supports most of the same modern Solaris systems as OpenBSD (Oddly, no Ultra-2 SCSI support, but FreeBSD does work on E220/E250) and offers SMP support for systems that have multiple CPUs)

Sudo advocacy

Some additional comments on the subject of "sudo" (http://www.courtesan.com/sudo/).

Sudo (Super User Do) is a popular solution for Unix access control, permitting regular users to run certain commands as root or as a role account, without the risks of shared passwords, and without the need for users to memorize yet another password. On many of my personal Unix systems, "sudo" is the only file with "setuid root" permission!

Has there been any consideration of the option to use the advanced (http://www.courtesan.com/sudo/intro.html) features of the "sudo" package? For example, maintaining a single global "sudoers" file on a (secure) central management host, "pushing" copies of this single standard configuration file to all managed Unix servers?

Use of a single global, centrally-managed "sudoers" file offers numerous advantages:

• Simplifies changes that affect many servers, including adding and removing access to commands and user access (allowing for near instantaneous hire/fire access updates).
• Grouping of users, of hosts, and of commands allows discrete access control from a single global file.
• This type of centrally-controlled "sudo" deployment on Solaris is used at many large corporations, including Lockheed Martin.
• Without the need for users (or even most administrators) to know the root password, this password can be stored more securely, and "root" can be a restricted "role" account under Solaris 8 RBAC.
• One single file to audit for access control of root and role account commands for all hosts.
• Automatic generation and reporting of command audit trails, locally and/or to a central log host.

I am aware of a few drawbacks, including the reasons Data Security uses this approach for other configuration files, but not for "sudoers":
Compromise of any host which uses the global "sudoers" file exposes sensitive information about the purpose, users, and access controls on other hosts using the same "sudoers" configuration.
Compromise of the central management host may make it easier to compromise the client hosts.
Effective security requires recompiling "sudo" to use SecurID authentication instead of passwords.

Automatic updating of the "sudoers" file on large numbers of remote hosts can be accomplished in a number of ways. Through the use of "ssh" and "rsync", changes to the global configuration can be distributed, via either "push" or "pull" scripting, quickly and efficiently.