In other news not reported on slashdot, RedHat Network, the only way to get critical updates for RedHat Enterprise Linux, has been down ALL WEEKEND. Their web site says this is a planned outage, but it most certainly was not announced to paying customers who had scheduled and announced outages requiring access to RHN this weekend.
About 50% of which are dynamic PHP or Perl pages, 40% of which involve hitting MySQL, which is running on the same server, or an external IMAP server. You see, this machine is mostly an IMP webmail gateway.
And every hit is 128-bit SSL.
unet.brandeis.edu is a 2-year-old valinux box with a 350MHz Pentium II and 128MB RAM.
Load average is usually around 1.5.
Uptime since January 3rd, when management allowed us to turn the servers back on after a pointless y2k shutdown, is 100.0%.
We have new hardware, but haven't taken the time to cut it over because the old stuff is working.
An identical machine is serving as our web proxy. For one day's statistics, see http://brandeis.edu/~rcgraves/squidc.html
I'm not making this up.
That's a 350MHz Pentium II with 128MB RAM serving 700,000 http hits, 5.3GB data, with Squid 2.3. Load average is typically around 0.5.
I verified the exploit and upgraded all my end-user shell boxes before 2am.
Sendmail did the right thing. Details of the vulnerability were already publicly available, but had been misreported as Sendmail bugs.
The impact is that any local user (local shell access is required) can become root using techniques simular to those effective against pre-v8 versions of Sendmail. I've found two other vulnerable applications, surely there are more. If you can't figure it out given the information provided, good. Just upgrade your kernel.
ssh2 does not implement the ssh1 protocols, so ssh2 simply execs ssh1 when a v1.5 client connects. Everyone installs ssh2 in ssh1 compatibility mode because the free Mac/Win ssh clients, like NiftyTelnet and ttssh, only do ssh1.
The ssh1 RPMs currently on ftp.hacktic.nl and mirrors (replay.com is no more) have been patched to avoid this problem. I assume debian is OK too.
All the BSD's use OpenSSH now, so they're fine as long as you're up to date.
Unamericans should be OK because they don't link with RSAREF.
Americans who haven't linked with RSAREF are violating RSA's patent.
They simply will not license RSA to end users. A BSAFE development license is more expensive than any of the commercial servers. Your cheapest approach is Raven or (if you're Linux) RedHat Secure Server.
If your client needs more complete documentation, service, and support, get Stronghold.
It would have been more polite to wait for the answer on the mirror list.
This was a goof on redhat's part... they were going to keep it restricted until Monday.
Anyway this is a much better state of affairs than the 6.0 release, which leaked from a few mirrors before it was available on redhat and before other mirrors had a chance to get it.
Our mirror completed around midnight. I'm not eager to hose our bandwidth quite yet, so I'm keeping it private til Monday.
We use Oracle for Linux for serious production applications and MySQL for simple web stuff (which includes serious production applications like managing authenticated sessions). PHPLIB and Perl DBI make it easy to switch.
I wouldn't consider other closed-source databases. Nothing else, not even DB2, has the technical depth and experience and cool things like real optimistic locking, which enables apps that are simply impossible in Sybase or MS-SQL.
Read the MySQL docs. They have a good discussion of the tradeoffs and, because they're not selling licenses all the time, there's little marketing BS.
PostgreSQL is getting to be a contender with some of the best virtues of MySQL and Oracle, but I don't feel it's as stable as either yet. The current team only really started to make the code their own with the last release. Oracle, MySQL, and Sybase have more experience.
If you don't need a heavyweight SQL database, don't use one. Applications like sendmail and LDAP where transactions are simple and replication is desired are much better off with GDBM or Sleepycat.
Like MIT, Stanford's CS department has a new Gates building.
As at MIT, there are no production Windows NT Servers in the Gates building.
However, the Graduate School of Business (both Stanford's and MIT's) is heavily Microsoft-biased. Everyone *must* have a computer in the GSB NT Domain.
It's a good strategy -- people who don't know any better assume that the best and brightest MIT and Stanford CS students have some relationship with Microsoft, and the future PHBs who will eventually make the real decisions get indoctrinated.
Incidentally, behind the scenes, the Stanford GSB's entire infrastructure relies on two HP Vectras running ISC DHCPd. They were literally about to be thrown away because they weren't powerful enough to run NT anymore. Despite three months of effort by full-time Microsoft employees with the personal attention of Steve Ballmer (Stanford GSB alum), the high-end HP servers donated to the GSB could not be made to run Microsoft's DHCP server reliably. According to nmap, the primary server is still running the kernel I installed in December 1997. It's not unlikely that they haven't been rebooted since I left Stanford 18 months ago.
My new job is more fun.
Brandeis is small enough to lie below Microsoft's radar. For the most part, we get to make decisions based on merit. This means Linux, BSD, or OpenVMS on the server end, Windows NT on administrative desktops, and a mix of about 77% Win95/98, 22% MacOS, and 1% other in the dorms.
Everyone's paychecks come from Oracle for Linux -- pressure to move to Linux came from NT sysadmins unsatisfied with the reliability of Oracle on NT. Student records still live in 20-year-old software on the VAX (*probably* y2k compliant) because no off-the-shelf solution does everything the old COBOL hacks do.
This feature of ISC DHCPD and the DDNS features of w2k are totally unrelated.
The ISC DHCPD 3.1 feature referenced, and the patches to 2.0 which have been around for over a year, does this:
When a Windows 95/98/NT client, or a UNIX or any other client configured to send option 12, is assigned an IP address, the ISC DHCP server connects to the DNS server on the client's behalf to update its entry.
This allows you to secure your DNS server to accept (possibly DNSSec'd) updates from your DHCP server only.
The Microsoft DDNS solution does this:
After a Windows 2000 client has been assigned an address by the DHCP server, it contacts the DNS server directly to update its entry.
The Microsoft solution requires your DNS server to accept updates directly from your clients. The Microsoft solution does not attempt to support Win95/98/NT clients at all.
"...The DEFAULT authentication for Win2K is kerberos."
There I was addressing the current roaming user, using a non-Microsoft platform. I have a problem with DDNS in general, not just Microsoft's.
I don't think dynamic DNS solves the roaming machine problem because of the TTL and security issues. The problem it does help solve is plug- and-play -- you can fire up 100 w2k boxes on a network using a promiscuous DHCP server or even the client-autoconfigured range and they will all get registered in the DNS based on the network settings on the *client* end. Just like the Macintosh Chooser. How useful that is depends on what you plan to do with the information and how scalable it needs to be. In our environment, out-of-band end-user access through a secure web server is better.
To answer your question, as far as I've seen, the w2k DDNS client does not do kerberos or any other form of strong auth.
Internet Explorer does not and for the forseeable future will not do kerberos (according to the lead NT5 security engineer when I was in Redmond). The NT5/w2k version does some SID token-passing with proprietary headers, not SASL. You can't really fault MS for this, though, because there are no standards for kerberos over http. CMU keeps trying to get people to kerberise web applications, but Stanford gave up and went s/ident and even MIT makes x509 client certs for users rather than force kerberos on an unwilling application.
File & print service does do kerberos and can be configured to refuse to negotiate non-kerberised connections if you know that all clients and all servers on your network are guaranteed to be running w2k. In the real world, I expect WINS and legacy NT domains to last through 2010. We still have 2 key production NT 3.51 servers because the commercial off-the-shelf application they run is not reliable under NT 4.0. There are more architectural differences between NT4 and w2k than between NT3 and NT4.
I think dynamic DNS is a solution in search of a problem.
You say, "Its nice to be able to connect w/ a laptop anywhere on a 100+ subnet network and get the same domain name to resolve everytime."
Why?
How many people besides you regularly connect to a server running on your laptop?
Are you sure you control the TTL on your DNS server, every DNS server used by every client that talks to you, and every server you talk to?
What do you do when a remote site's TCP wrappers refuse access because they cached your old PTR record?
What assurances do you have that someone can't spoof your dynamic name and steal credentials? If you think you're authenticated by MAC address, try ifconfig eth0 hw de:ad:be:ef:01:23 (doesn't work with all enet cards, but does with the common ones). If you use kerberos, x509, or ssh host keys and you actually bother to verify them, then you have less of a problem, but many common services, like unencrypted web pages, have no end-to-end server verification protocol. Interestingly enough, Microsoft's NT domain protocols do not strongly authenticate the server to the client. If an attacker puts himself at the server's IP address and generates a nonrandom nonce, you lose.
Microsoft considered strongly authenticating DDNS to be too hard (and nonexportable), so they basically trust whatever you put in the Network Control Panel (or a packet manufactured with smblib) as long as the name has not already been taken. Taken names can probably be freed up with the same sort of games people play to take over IRC channels. Bzzt! Game Over.
Microsoft says it plans to get rid of WINS, but the initial implementation brings all the instability and insecurity of WINS to DNS. No thanks. The non-Microsoft solutions tend not to be much better at this time.
Out-of-band authentication like MyIP or the old ml.org web page works, but that ain't DDNS, that's end-user access to static DNS... which can be a good thing. We provide something similar for our students.
In case deja URLs aren't permanent, search for "WINS" in comp.os.ms-wendows.networking.win95 during January 1996.
I was intimidated the first time I looked at kickstart, but now that fezbox has shown how easy it is it's going to save me a lot of time. The %post commands are *very* nice for installing the gaggle of post-6.0 updates, stripping inetd, etc.
Sure you have a choice. RBL exceptions.
on
NSI to be RBL'ed?
·
· Score: 2
> We are a user of RBL and if they do eventually > put Internic on RBL we would have no choice > but to turn RBL off.
No, just add them to ACCESSDB (/etc/mail/access) as OK.
Any time the RBL blocks someone, you get an easily parsed log message. If you're worried about losing mail, make RBL return a 45x rather than 55x; the sender's server will retry.
In a year of using the RBL I don't believe we've inconvenienced more than a handful of non-spammers. The only case that comes to mind is an open relay at UPenn -- 99% of what the RBL delayed from that relay was spam, but there might have been some legit users too. And then they fixed the problem.
MAPS doesn't go off half-cocked like ORBS. They only add to the list after the site has had ample opportunity to respond. It's not really "realtime."
15 Linux boxes, 2 HP9000s, 5 IRIX, a dozen NT, handful of Macs, 4 VMS, and one NetApp toaster backed up through Linux NFS-mount (poor Linux 2.0 NFS performance is an advantage here... when mounted on the HP it pretty much killed the network).
The interface isn't that terrible. 5.5 is much better. We have had intermittent problems backing up a 36GB RAID filesystem (Linux 2.2) though.
It's far from free, and the server requires NT or a commercial UNIX. We run it on HP-UX 10.20. But for multiplatform backup on a high-end tape changer robot, you need o go the commercial route.
A 6350, which is the rack-optimized 6300, and only 2 Xeons (1MB cache). It's going to run Oracle and a bunch of other stuff. We have run Oracle on NT for years (3.51 mostly, which we've found much more stable than 4.0), and don't want to subject ourselves to random crashes anymore.
Things that jump out at me:
echo 2048 >/proc/sys/kernel/file-max, already mentioned. This is in the Apache FAQ.
The MegaRAID driver was at version 0.94 at the time of the test. Had they asked, Dell would have sent it to them. But really the MegaRAID is a poor choice; for less than the price Dell charges for a MegaRAID bundled with a server, you can mail-order a Mylex AcceleRAID ($1700-some and in stock at buy.com), which is faster and better supported under Linux. It is true that even today, with the 0.96 driver in the 2.2.5 kernel, you will find only version 0.92 on ami.com. This is an excellent reason not to buy from AMI.
Warning: Do not buy a PERC II card from Dell today. In typical Dell fashion, they are shipping some Adaptec 789x thing that has no Linux driver without changing the part number that used to refer to a MegaRAID. This is one of many excellent reasons not to buy from Dell. Why do we continue to do it? Well, we've bought some VAResearch boxes, but they simply can't match Dell's ability to throw hardware at you quickly if something is wrong. It doesn't matter how clueless Dell is if you know what you want, and their cluelessness can be an advantage at times. Their sales droids are not always the brightest, but there are lots of them, they return your calls, and they will jump through hoops (if you explain how) to make you happy. Also, Dell's default server warranty is 3 years, first ON-SITE. That's a big factor if your power supply blows up at a bad time. I think Penguin is catching up, though. Maybe next time.
Slashdot Mirror
In other news not reported on slashdot, RedHat Network, the only way to get critical updates for RedHat Enterprise Linux, has been down ALL WEEKEND. Their web site says this is a planned outage, but it most certainly was not announced to paying customers who had scheduled and announced outages requiring access to RHN this weekend.
About 50% of which are dynamic PHP or Perl pages, 40% of which involve hitting MySQL, which is running on the same server, or an external IMAP server. You see, this machine is mostly an IMP webmail gateway.
And every hit is 128-bit SSL.
unet.brandeis.edu is a 2-year-old valinux box with a 350MHz Pentium II and 128MB RAM.
Load average is usually around 1.5.
Uptime since January 3rd, when management allowed us to turn the servers back on after a pointless y2k shutdown, is 100.0%.
We have new hardware, but haven't taken the time to cut it over because the old stuff is working.
An identical machine is serving as our web proxy. For one day's statistics, see http://brandeis.edu/~rcgraves/squidc.html
I'm not making this up.
That's a 350MHz Pentium II with 128MB RAM serving 700,000 http hits, 5.3GB data, with Squid 2.3. Load average is typically around 0.5.
I verified the exploit and upgraded all my end-user shell boxes before 2am.
Sendmail did the right thing. Details of the vulnerability were already publicly available, but had been misreported as Sendmail bugs.
The impact is that any local user (local shell access is required) can become root using techniques simular to those effective against pre-v8 versions of Sendmail. I've found two other vulnerable applications, surely there are more. If you can't figure it out given the information provided, good. Just upgrade your kernel.
There is no remote exploit.
Mozilla is open source distributed from the USA without crypto.
Presumably these boxes would ship from the USA.
Are they then not going to ship with crypto?
Would it be legal under the MPL to link with a crippled closed-source crypto library?
ssh2 does not implement the ssh1 protocols, so
ssh2 simply execs ssh1 when a v1.5 client
connects. Everyone installs ssh2 in ssh1
compatibility mode because the free Mac/Win ssh
clients, like NiftyTelnet and ttssh, only do ssh1.
The ssh1 RPMs currently on ftp.hacktic.nl and
mirrors (replay.com is no more) have been patched
to avoid this problem. I assume debian is OK too.
All the BSD's use OpenSSH now, so they're fine as
long as you're up to date.
Unamericans should be OK because they don't link
with RSAREF.
Americans who haven't linked with RSAREF are
violating RSA's patent.
They simply will not license RSA to end users.
A BSAFE development license is more expensive
than any of the commercial servers. Your cheapest
approach is Raven or (if you're Linux) RedHat
Secure Server.
If your client needs more complete documentation,
service, and support, get Stronghold.
It would have been more polite to wait for the
answer on the mirror list.
This was a goof on redhat's part... they were
going to keep it restricted until Monday.
Anyway this is a much better state of affairs
than the 6.0 release, which leaked from a few
mirrors before it was available on redhat and
before other mirrors had a chance to get it.
Our mirror completed around midnight. I'm not
eager to hose our bandwidth quite yet, so I'm
keeping it private til Monday.
We use Oracle for Linux for serious production
applications and MySQL for simple web stuff
(which includes serious production applications
like managing authenticated sessions). PHPLIB
and Perl DBI make it easy to switch.
I wouldn't consider other closed-source
databases. Nothing else, not even DB2, has the
technical depth and experience and cool things
like real optimistic locking, which enables
apps that are simply impossible in Sybase or
MS-SQL.
Read the MySQL docs. They have a good discussion
of the tradeoffs and, because they're not
selling licenses all the time, there's little
marketing BS.
PostgreSQL is getting to be a contender with
some of the best virtues of MySQL and Oracle,
but I don't feel it's as stable as either yet.
The current team only really started to make
the code their own with the last release. Oracle,
MySQL, and Sybase have more experience.
If you don't need a heavyweight SQL database,
don't use one. Applications like sendmail and
LDAP where transactions are simple and
replication is desired are much better off with
GDBM or Sleepycat.
Like MIT, Stanford's CS department has a new
Gates building.
As at MIT, there are no production Windows NT
Servers in the Gates building.
However, the Graduate School of Business (both
Stanford's and MIT's) is heavily Microsoft-biased.
Everyone *must* have a computer in the GSB NT
Domain.
It's a good strategy -- people who don't know any
better assume that the best and brightest MIT and
Stanford CS students have some relationship with
Microsoft, and the future PHBs who will eventually
make the real decisions get indoctrinated.
Incidentally, behind the scenes, the Stanford
GSB's entire infrastructure relies on two HP
Vectras running ISC DHCPd. They were literally
about to be thrown away because they weren't
powerful enough to run NT anymore. Despite
three months of effort by full-time Microsoft
employees with the personal attention of Steve
Ballmer (Stanford GSB alum), the high-end HP
servers donated to the GSB could not be made to
run Microsoft's DHCP server reliably. According
to nmap, the primary server is still running the
kernel I installed in December 1997. It's not
unlikely that they haven't been rebooted since I
left Stanford 18 months ago.
My new job is more fun.
Brandeis is small enough to lie below Microsoft's
radar. For the most part, we get to make decisions
based on merit. This means Linux, BSD, or OpenVMS
on the server end, Windows NT on administrative
desktops, and a mix of about 77% Win95/98, 22%
MacOS, and 1% other in the dorms.
Everyone's paychecks come from Oracle for Linux --
pressure to move to Linux came from NT sysadmins
unsatisfied with the reliability of Oracle on NT.
Student records still live in 20-year-old software
on the VAX (*probably* y2k compliant) because no
off-the-shelf solution does everything the old
COBOL hacks do.
This feature of ISC DHCPD and the DDNS features
of w2k are totally unrelated.
The ISC DHCPD 3.1 feature referenced, and the
patches to 2.0 which have been around for over a
year, does this:
When a Windows 95/98/NT client, or a UNIX or any
other client configured to send option 12, is
assigned an IP address, the ISC DHCP server
connects to the DNS server on the client's
behalf to update its entry.
This allows you to secure your DNS server to
accept (possibly DNSSec'd) updates from your
DHCP server only.
The Microsoft DDNS solution does this:
After a Windows 2000 client has been assigned an
address by the DHCP server, it contacts the DNS
server directly to update its entry.
The Microsoft solution requires your DNS server to
accept updates directly from your clients. The
Microsoft solution does not attempt to support
Win95/98/NT clients at all.
Assuming you configure BIND 8.2 to accept DDNS
requests with no authentication whatsoever.
If you do that, you deserve what you get.
"...The DEFAULT authentication for Win2K is kerberos."
There I was addressing the current roaming user, using a non-Microsoft platform. I have a problem
with DDNS in general, not just Microsoft's.
I don't think dynamic DNS solves the roaming
machine problem because of the TTL and security
issues. The problem it does help solve is plug-
and-play -- you can fire up 100 w2k boxes on a
network using a promiscuous DHCP server or even
the client-autoconfigured range and they will
all get registered in the DNS based on the
network settings on the *client* end. Just like
the Macintosh Chooser. How useful that is depends
on what you plan to do with the information and
how scalable it needs to be. In our environment,
out-of-band end-user access through a secure web
server is better.
To answer your question, as far as I've seen, the
w2k DDNS client does not do kerberos or any other
form of strong auth.
Internet Explorer does not and for the forseeable future will not do kerberos (according to the lead
NT5 security engineer when I was in Redmond). The
NT5/w2k version does some SID token-passing with
proprietary headers, not SASL. You can't really
fault MS for this, though, because there are no
standards for kerberos over http. CMU keeps trying
to get people to kerberise web applications, but
Stanford gave up and went s/ident and even MIT
makes x509 client certs for users rather than
force kerberos on an unwilling application.
File & print service does do kerberos and can be
configured to refuse to negotiate non-kerberised
connections if you know that all clients and all
servers on your network are guaranteed to be
running w2k. In the real world, I expect WINS and
legacy NT domains to last through 2010. We still
have 2 key production NT 3.51 servers because the
commercial off-the-shelf application they run is
not reliable under NT 4.0. There are more
architectural differences between NT4 and w2k than
between NT3 and NT4.
I think dynamic DNS is a solution in search of a
E XT=935866614.1926103089&hitnum=9
problem.
You say, "Its nice to be able to connect w/ a laptop anywhere on a 100+ subnet network and get the same domain name to resolve everytime."
Why?
How many people besides you regularly connect to
a server running on your laptop?
Are you sure you control the TTL on your DNS
server, every DNS server used by every client
that talks to you, and every server you talk to?
What do you do when a remote site's TCP wrappers
refuse access because they cached your old PTR
record?
What assurances do you have that someone can't
spoof your dynamic name and steal credentials? If
you think you're authenticated by MAC address,
try ifconfig eth0 hw de:ad:be:ef:01:23 (doesn't
work with all enet cards, but does with the common
ones). If you use kerberos, x509, or ssh host keys
and you actually bother to verify them, then you
have less of a problem, but many common services,
like unencrypted web pages, have no end-to-end
server verification protocol. Interestingly
enough, Microsoft's NT domain protocols do not
strongly authenticate the server to the client.
If an attacker puts himself at the server's IP
address and generates a nonrandom nonce, you lose.
Microsoft considered strongly authenticating
DDNS to be too hard (and nonexportable), so they
basically trust whatever you put in the Network
Control Panel (or a packet manufactured with
smblib) as long as the name has not already been
taken. Taken names can probably be freed up with
the same sort of games people play to take over
IRC channels. Bzzt! Game Over.
Microsoft says it plans to get rid of WINS, but
the initial implementation brings all the
instability and insecurity of WINS to DNS. No
thanks. The non-Microsoft solutions tend not to
be much better at this time.
Out-of-band authentication like MyIP or the old
ml.org web page works, but that ain't DDNS,
that's end-user access to static DNS... which
can be a good thing. We provide something similar
for our students.
In case deja URLs aren't permanent, search for "WINS" in comp.os.ms-wendows.networking.win95 during January 1996.
http://x22.deja.com/getdoc.xp?AN=135549278&CONT
I was intimidated the first time I looked at
o /RH
kickstart, but now that fezbox has shown how easy
it is it's going to save me a lot of time. The
%post commands are *very* nice for installing the
gaggle of post-6.0 updates, stripping inetd, etc.
To install from a ftp or http server, use:
url --url http://hostname.of.server/path/to/RH
for http or:
url --url ftp://hostname.of.server/path/to/RH
for ftp. To use a non-anonymous server, use:
url --url ftp://username:password@hostname.of.server/path/t
To use a FTP or HTTP proxy, use:
url --url ftp://server/path/to/RH --proxy proxy.server.hostname --proxyport 201
> We are a user of RBL and if they do eventually
> put Internic on RBL we would have no choice
> but to turn RBL off.
No, just add them to ACCESSDB (/etc/mail/access)
as OK.
Any time the RBL blocks someone, you get an
easily parsed log message. If you're worried
about losing mail, make RBL return a 45x rather
than 55x; the sender's server will retry.
In a year of using the RBL I don't believe we've
inconvenienced more than a handful of
non-spammers. The only case that comes to mind is
an open relay at UPenn -- 99% of what the RBL
delayed from that relay was spam, but there might
have been some legit users too. And then they
fixed the problem.
MAPS doesn't go off half-cocked like ORBS. They
only add to the list after the site has had ample
opportunity to respond. It's not really
"realtime."
15 Linux boxes, 2 HP9000s, 5 IRIX, a dozen NT, handful of Macs, 4 VMS, and one NetApp toaster backed up through Linux NFS-mount (poor Linux 2.0 NFS performance is an advantage here... when mounted on the HP it pretty much killed the network).
The interface isn't that terrible. 5.5 is much better. We have had intermittent problems backing up a 36GB RAID filesystem (Linux 2.2) though.
It's far from free, and the server requires NT or a commercial UNIX. We run it on HP-UX 10.20. But for multiplatform backup on a high-end tape changer robot, you need o go the commercial route.
A 6350, which is the rack-optimized 6300, and only 2 Xeons (1MB cache). It's going to run Oracle and a bunch of other stuff. We have run Oracle on NT for years (3.51 mostly, which we've found much more stable than 4.0), and don't want to subject ourselves to random crashes anymore.
/proc/sys/kernel/file-max, already mentioned. This is in the Apache FAQ.
Things that jump out at me:
echo 2048 >
The MegaRAID driver was at version 0.94 at the time of the test. Had they asked, Dell would have sent it to them. But really the MegaRAID is a poor choice; for less than the price Dell charges for a MegaRAID bundled with a server, you can mail-order a Mylex AcceleRAID ($1700-some and in stock at buy.com), which is faster and better supported under Linux. It is true that even today, with the 0.96 driver in the 2.2.5 kernel, you will find only version 0.92 on ami.com. This is an excellent reason not to buy from AMI.
Warning: Do not buy a PERC II card from Dell today. In typical Dell fashion, they are shipping
some Adaptec 789x thing that has no Linux driver without changing the part number that used to refer to a MegaRAID. This is one of many excellent reasons not to buy from Dell. Why do we continue to do it? Well, we've bought some VAResearch boxes, but they simply can't match Dell's ability to throw hardware at you quickly if something is wrong. It doesn't matter how clueless Dell is if you know what you want, and their cluelessness can be an advantage at times. Their sales droids are not always the brightest, but there are lots of them, they return your calls, and they will jump through hoops (if you explain how) to make you happy. Also, Dell's default server warranty is 3 years, first ON-SITE. That's a big factor if your power supply blows up at a bad time. I think Penguin is catching up, though. Maybe next time.
And why is it so small?
I'd like a sculptured Dvorak or Maltron, please,
but it needs to have the control key in a reasonable spot.
I'd remap it, but I don't see an obvious candidate. They've already optimized away capslock.