So apparently YouTube, according to a Pakistani telecommunications authority, carries content that is “deemed offensive to Islam.
So the ISP either purposefully or accidentally, added custom routing configurations to it’s routers to block YouTube. The unfortuate side-effect was that these BGP announcements were propagated to a large part of the world’s routers, taking YouTube offline for a good number of people.
This fellow has a pretty good summation/chronology of what happened:
Renesys Blog: Pakistan hijacks YouTube
Posted by Brian Blood as Routers and Firewalls, Soap Box at 11:25 AM CST
No Comments »
Server Monitor is an application that allows you to monitor the health of several Xserves over the network:
Sometimes the application gets a bit cranky about the connections it makes to the servers and reports that it can’t communicate or as you see here in the picture “reply not understood”. So we don’t really use it for serious monitoring other than as a cursory glance usually to check some items.
However, Apple really takes the cake with this knowledge-base article:
Xserve: Server Monitor does not authenticate with server over subnet
in which they claim that the way to fix the problems with their SOFTWARE, is to:
- Make the necessary changes to the username or password using Server Monitor.
- Quit Server Monitor.
- Shut down the Xserve that is the target of these changes.
- Remove the power cord from the back of the Xserve.
- Wait 30 seconds and plug the power cord back in.
- Power the server back on.
This sounds suspiciously similar to something an old tech friend of mine once told me:
There are sound scientifically proven reasons why one must sometimes sacrifice a chicken in order to get a SCSI chain to work.
Ugh.
Posted by Brian Blood as Colocation, Hardware, OS X Server, Servers, Soap Box at 11:33 PM CST
No Comments »
Was reading this article today on Google’s initiative to expand the economics of alternative energy:
Google expands into alternative energy
MICHAEL LIEDTKE, AP Business Writer
I love this paragraph here:
Toward that end, Google aims to produce one gigabyte of power from renewable energy at prices below the rates of electricity generated at coal-burning plants. One gigabyte power would be enough to supply the needs of a city the size of San Francisco.
I’m not exactly sure what one “gigabyte” of power is, but if Google is using them, I’m sure it’s a lot. 
I wonder if it’s comparable to the power you can generate by tapping into a clock tower that’s about to be struck by lightning.
Semi-related is the speculation that Google is building their own 10Gbit optical switches.
Guess they’ll combine their gigabytes of power with the gigabits of light. See: I knew lightning would be in there somewhere!
Posted by Brian Blood as Hardware, Soap Box at 9:14 AM CST
No Comments »
Here is a list of the basics that every system administrator should implement:
- Set your Reverse DNS. Don’t leave it empty.
- Have geographically separated DNS servers
- MTAs should have properly formed HELO names
- rDNS should match the HELO on your MTA
- HELO should resolve to your IP address
- MX records must point to A records
- Filter Bogons at the first opportunity in your network architecture and at appropriate routing points.
- More to come
Posted by Brian Blood as General, Mail Server, Routers and Firewalls, Servers, Soap Box at 3:53 PM CST
No Comments »
Question to my Apple Authorized dealer that I just ordered Leopard
Server from to install on an Xserve G4:
> can you find out for me how I can get CD versions of the Leopard
> Server installer?
> we have some xserves that do not have DVD capable optical drives.
His Reply:
> From what I understand it doesn’t exist, one of the requirement of
> Leopard is a DVD drive. I’m guessing you’ll have to
> boot from another computer that has a DVD drive in Firewire Target
> mode.
My retort:
> From:
> http://www.apple.com/server/macosx/specs.html
> System Requirements
>
> Mac server or desktop computer with an Intel, PowerPC G5, or
> PowerPC G4 (867MHz or faster) processor; 1GB of physical RAM; 20GB
> of available disk space.
His Reply (looks like text pulled from somewhere)
> This is the first release of Mac OS X that’s not available in any
> form on CD, as all consumer-class computers that are capable of
> running Leopard also have at least a Combo Drive (DVD reading plus
> CD writing). Some Xserve models can run Mac OS X Server 10.5 but
> have only a CD-ROM drive; for such machines, you can perform a
> network installation using another computer running Leopard Server,
> or put the computer into Target Disk Mode and install Leopard
> Server from another computer that has a DVD reader.
Asking the Google, I find that text here:
http://db.tidbits.com/article/9243
So, installing Leopard Server on an Xserve G4 requires some sort of external piece of hardware. (Which of course, won’t be supplied by Apple (-; )
Target Disk Mode is not really an option as TGM on an Xserve G4 only exposes the device in Bay 1. Since we always build our Xserve G4s out with Mirrored arrays, we couldn’t start with a fresh pair of disks to install onto as a RAID pair. Perhaps a single drive RAID mirror might work and then add in second disk once booted up.
Ugh. I hate having to perform convoluted workarounds just to install an OS.
I guess all machines are equally supported for Leopard, just some are more equal than others.
UPDATE: A really good suggestion was made to me on the OS X Server mailing list of making an image of the Leopard disc, then restoring onto a partition of a external firewire drive. This will boot the machine and run the installer just as if from an disc.This can even be used to put multiple install partitions of any number of install discs.
Posted by Brian Blood as OS X Server, Servers, Soap Box at 7:23 PM CST
No Comments »
An email exchange I had with a very smart colleague regarding how one defines “Reliability”, specifically in relation to Active Directory, of which I admit to knowing very little, so the discussion mostly centers on philosophical perspectives.
On 8/18/07 12:48 AM, “Wm.” wrote:
>
> So what you are saying is the protocol definition makes provision for
> what the client is supposed to do in the attempt to hide server
> outages from the user?
Yes. If that is what the protocol is designed to do.
> Do the following protocols define the service
> reliability as a function of the client’s ability to find a working
> server? (HTTP, NTP,WebDAV, AFP, SMB, FTP, IKE, VNC, IPP, ARD, IMAP,
> POP, SMTP, LDAP, Kerberos)
Not that I know of:
WebDAV, AFP, SMB, FTP, VNC, IPP, ARD, IMAP, POP
Yes:
NTP
Maybe:
LDAP, Kerberos
I don’t know:
IKE
Kind of:
HTTP, SMTP
> AD is a summation of LDAP, Kerberos and some proprietary mechanisms
> that Microsoft stacks on top. The actual’service’ is either LDAP or
> Kerberos depending upon the request.
ok. That’s more than I knew before having never looked at what AD is.
> It is kinda like going to Avis and renting a car. They put 30 on the
> lot and it is the client’s job to find the car ’service’ that works.
> This alleviates the Avis ’server’ from responsibility for having
> working ’services’. As long as one car starts, no problem. Half of
> them may not start but it is not a problem unless all of them don’t
> start?
Not a very good analogy, or merely one that just fits to bolster your point.
You are trying to take your particular definition of “service reliability”
and apply it in a one-size fits all manner.
The true answer (like most things in life) is: It Depends
Some protocols are merely information request oriented protocols, like DNS
or NTP. These protocols tend have methods for dealing with inaccessible
sources of data.
Some are data access/transaction oriented protocols (any file sharing
protocol, mail). These protocols tend to not have “redundancy” as the
ability to have a data exchange transaction be mirrored across physical
servers difficult due to it being harder to replicate data across those
physical systems.
Some protocols have a pseudo redundancy in them. HTTP can redirect a
requestor to a different source to complete the data exchange. SMTP can give
a temporary deferment for data exchange.
As for AD: From what little I know of it, it is mostly a information request
system (where am I, can I get an auth token using these credentials, is this
system authorized to access me, etc) and that data can, for the most part,
be replicated easily across systems, much like DNS is replicated across
servers to serve out the same answers for a single question.
So a better analogy for the Avis world would be something like:
Are there multiple sources for me to get an answer to the Ultimate Question
of Life, The Universe and Everything:
“Dude, Where’s My Car?”
If none of the agents can answer the question, then yeah, the service sucks.
One thing I sent to Bill offline that I’ll include here for the benefit of
anyone else that is still reading:
—
If the protocol in question has to use BROADCAST traffic in order to
discover redundant systems to query then I consider that to be a poor design
choice for redundancy.
—
> On Aug 6, 2007, at 3:08 PM, Brian Blood wrote:
>
>> On 8/6/07 12:20 PM, “Wm.” wrote:
>>
>>> Does anyone recall coming across a white paper relative to measuring
>>> service reliability and collecting metrics on such.
>>>
>>> I am in a discussion with Active Directory admins who insist that if
>>> an AD client can root around and find a working server, then their
>>> service reliability metric is 100%. My stance is that service
>>> reliability is measured not by the workaround that the client
>>> performs but the availability of the service at the server’s point of
>>> presence (aka domain name).
>>
>>
>> I think you are dealing in semantics here.
>>
>> Look at DNS for an example.
>>
>> With most systems, a domain name is handled by two dns servers.
>>
>> If one of these is down, then the other covers traffic that would
>> have been
>> down.
>>
>> This redundancy is part of the dns protocol.
>>
>> While the DNS Service as a whole would have 100% reliability,
>> because of how
>> the protocol is designed, the reliability of the specific server
>> would not
>> be 100%.
>>
>>
>> So, the answer, as usual, is: it depends on what system you are
>> analyzing.
>>
>> If an AD client as part of the AD protocol can look for multiple
>> servers to
>> auth against, then the reliability of the AD SERVICE on that
>> network will be
>> measured as a whole.
>>
>>
>> In short, I think you are wrong.
>>
>>
>>
>> Brian
Posted by Brian Blood as General, Servers, Soap Box at 6:45 PM CDT
No Comments »