Weblogs for sneex
#8
Posted by sneex on Wed 8 Apr 2009 at 14:29
Recently I came across this command running in the morning time-frame on my system:
su nobody -s /bin/sh -c /usr/bin/find / -ignore_readdir_race \( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -type d -regex '\(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/alex$\)\|\(^/var/spool$\)\|\(^/sfs$\)\|\(^/media$\)' \) -prune -o -print0
I know *what* it is doing but I am not sure where it is coming from... Has anyone seen this command or one similar to it? Any ideas about it and where it could be hiding would be most helpful :)
su nobody -s /bin/sh -c /usr/bin/find / -ignore_readdir_race \( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -type d -regex '\(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/alex$\)\|\(^/var/spool$\)\|\(^/sfs$\)\|\(^/media$\)' \) -prune -o -print0
I know *what* it is doing but I am not sure where it is coming from... Has anyone seen this command or one similar to it? Any ideas about it and where it could be hiding would be most helpful :)
#7
Posted by sneex on Tue 30 Sep 2008 at 21:54
Basic Authentication? Is it dead? I have an old RH9 server that is dying and the powers that be copied the data and old Apache config files over to my shiney (relatively) new Debian AMD64 box running Apache2 but we think Basic Authentication is broken. Since I didn't use basic authentication before this move I don't know if it was "broken or working" before :P Does anyone out there in Debian land have any insight or could maybe point me in better direction? This is the simplest VirtualHost example I can give that is not working: http://sneex.pastebin.ca/1214943
Thanks!
PS - My system(s) are - Debian Etch on AMD64 running Apache2
srv0:/etc/apache2/sites-available# apache2ctl -M
Loaded Modules:
core_module (static)
log_config_module (static)
logio_module (static)
mpm_prefork_module (static)
http_module (static)
so_module (static)
alias_module (shared)
auth_basic_module (shared)
auth_digest_module (shared)
auth_pam_module (shared)
auth_plain_module (shared)
auth_sys_group_module (shared)
authn_file_module (shared)
authz_default_module (shared)
authz_groupfile_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
cgi_module (shared)
dav_module (shared)
dav_fs_module (shared)
dir_module (shared)
env_module (shared)
info_module (shared)
jk_module (shared)
mime_module (shared)
python_module (shared)
negotiation_module (shared)
perl_module (shared)
php4_module (shared)
rewrite_module (shared)
setenvif_module (shared)
ssl_module (shared)
status_module (shared)
Syntax OK
srv0:/etc/apache2/sites-available# apache2ctl -v
Server version: Apache/2.2.3
Server built: Apr 16 2008 21:17:45
Thanks!
PS - My system(s) are - Debian Etch on AMD64 running Apache2
srv0:/etc/apache2/sites-available# apache2ctl -M
Loaded Modules:
core_module (static)
log_config_module (static)
logio_module (static)
mpm_prefork_module (static)
http_module (static)
so_module (static)
alias_module (shared)
auth_basic_module (shared)
auth_digest_module (shared)
auth_pam_module (shared)
auth_plain_module (shared)
auth_sys_group_module (shared)
authn_file_module (shared)
authz_default_module (shared)
authz_groupfile_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
cgi_module (shared)
dav_module (shared)
dav_fs_module (shared)
dir_module (shared)
env_module (shared)
info_module (shared)
jk_module (shared)
mime_module (shared)
python_module (shared)
negotiation_module (shared)
perl_module (shared)
php4_module (shared)
rewrite_module (shared)
setenvif_module (shared)
ssl_module (shared)
status_module (shared)
Syntax OK
srv0:/etc/apache2/sites-available# apache2ctl -v
Server version: Apache/2.2.3
Server built: Apr 16 2008 21:17:45
#6
Posted by sneex on Mon 9 Jun 2008 at 17:54
Request for comments -
I wrote the below to somewhat ease the creation of making self-signed certificates -- but while the script executes without error Apache2 (since the SSL update) will not start. I get this error:
[Mon Jun 09 12:17:23 2008] [error] Unable to configure RSA server private key
[Mon Jun 09 12:17:23 2008] [error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
I wrote the below to somewhat ease the creation of making self-signed certificates -- but while the script executes without error Apache2 (since the SSL update) will not start. I get this error:
[Mon Jun 09 12:17:23 2008] [error] Unable to configure RSA server private key
[Mon Jun 09 12:17:23 2008] [error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
This entry has been truncated read the full entry.
#5
Posted by sneex on Mon 27 Aug 2007 at 23:27
[Debian 4 on AMD64 64-Bits]
For the longest time everything under AMD64 appears quiet; until today I noticed a 256T (tera bytes!) /proc/kcore file on one of my servers ... 256T?
I realize that /proc/kcore doesn't truly take any real disk space on the server but I always thought that kcore 'size' was supposed to match 'real memory' size (which should be 8GB on the server in question -- not 256T!)
Thoughts? Comments? Opinions?
For the longest time everything under AMD64 appears quiet; until today I noticed a 256T (tera bytes!) /proc/kcore file on one of my servers ... 256T?
I realize that /proc/kcore doesn't truly take any real disk space on the server but I always thought that kcore 'size' was supposed to match 'real memory' size (which should be 8GB on the server in question -- not 256T!)
Thoughts? Comments? Opinions?
#4
Posted by sneex on Thu 28 Jun 2007 at 00:49
My expedition into AMD64: Note 2 ...
OK, so now that I'm done setting up and performance testing the new servers, I need to begin the migration. A little background: I began work here 9 weeks ago, replacing the most recent of about 5 guys who worked here anywhere between 3 weeks to 3 years. All of them have touched the software on the 6 old servers (which these 3 new servers will replace.) A few of the guys who used to work here were programmers of one type or another and I have NO IDEA where all the code is -- very few people left notes. So, after some thinking and digging I remembered another use for the 'locate' command; you know, the one you use in conjunction with updatedb?
Anyways, I know that there are a few hundred PHP, Perl, and related scripts on the old systems, but I have no idea where they all are. So, I wrote the below (modified from a Debian Security Manual shell trick) to, for example, find all the files which have the word 'perl' in them and copy them to a single directory so that I can see what they actually are (note that knowing where they came from at this stage is beside the point.) Once I see which file is what feature I can further refine the search criteria.
for i in { `locate *` }; do [ -f $i ] && { type=`file $i | grep -il perl`; \
[ -n "$type" ] && cp $i ~/Sys.perl.Code; }; done
[ ... the only draw back is that it will copy *all* files which have perl in them, regardless of whether or not they are 'text' scripts or 'gif' binaries... ]
More later...
-Sx-
OK, so now that I'm done setting up and performance testing the new servers, I need to begin the migration. A little background: I began work here 9 weeks ago, replacing the most recent of about 5 guys who worked here anywhere between 3 weeks to 3 years. All of them have touched the software on the 6 old servers (which these 3 new servers will replace.) A few of the guys who used to work here were programmers of one type or another and I have NO IDEA where all the code is -- very few people left notes. So, after some thinking and digging I remembered another use for the 'locate' command; you know, the one you use in conjunction with updatedb?
Anyways, I know that there are a few hundred PHP, Perl, and related scripts on the old systems, but I have no idea where they all are. So, I wrote the below (modified from a Debian Security Manual shell trick) to, for example, find all the files which have the word 'perl' in them and copy them to a single directory so that I can see what they actually are (note that knowing where they came from at this stage is beside the point.) Once I see which file is what feature I can further refine the search criteria.
for i in { `locate *` }; do [ -f $i ] && { type=`file $i | grep -il perl`; \
[ -n "$type" ] && cp $i ~/Sys.perl.Code; }; done
[ ... the only draw back is that it will copy *all* files which have perl in them, regardless of whether or not they are 'text' scripts or 'gif' binaries... ]
More later...
-Sx-
#3
Posted by sneex on Tue 26 Jun 2007 at 14:27
BTW - I did spend a couple days trying out the i386 686 BigMem with 32-bit user land as well as the x86_64 install (which is very similar to the overall CentOS 5 64-bit install.)
With disk based activity the x86_64 and pure AMD64 systems faired about the same in overall speed; however with regard to memory and especially network speeds - the pure AMD64 install was about 25 to 33 percent faster. Plus the x86_64 installation 'seemed' to be stuck/glued to a single CPU -- like it didn't want to distribute the load among all the CPUs.
Moving Tar'GZipped files between the systems, packing and unpacking and re-packing them, and sending them back between the systems was a lot better (maybe I'm biased) when using the pure AMD64 installation.
Speaking of speed; the following are what performance parameters I decided upon after a lot of testing (up to terabyte file sizes, etc.)
# 3ware SATA II 9550SX Controller Settings -
# echo cfq > /sys/block/sda/queue/scheduler \
# Set via Kernel option "elevator=xxx" (in /boot/grub/menu.lst)
# These 3 below are set inside /etc/init.d/rc.local
echo 128 > /sys/block/sda/queue/max_sectors_kb
echo 512 > /sys/block/sda/queue/nr_requests
blockdev --setra 16384 /dev/sda
Executing sync; hdparm -t -T /dev/sda1 ; a couple of times yields these results:
/dev/sda1:
Timing cached reads: 1814 MB in 2.00 seconds = 907.13 MB/sec
Timing buffered disk reads: 442 MB in 3.01 seconds = 146.94 MB/sec
/dev/sda1:
Timing cached reads: 1814 MB in 2.00 seconds = 907.08 MB/sec
Timing buffered disk reads: 434 MB in 3.01 seconds = 144.17 MB/sec
... which is about 50% faster that using the Debian defaults, and about 15% faster than 3Ware's recommended 'deadline' scheduler...
Also please see Section 1.
With disk based activity the x86_64 and pure AMD64 systems faired about the same in overall speed; however with regard to memory and especially network speeds - the pure AMD64 install was about 25 to 33 percent faster. Plus the x86_64 installation 'seemed' to be stuck/glued to a single CPU -- like it didn't want to distribute the load among all the CPUs.
Moving Tar'GZipped files between the systems, packing and unpacking and re-packing them, and sending them back between the systems was a lot better (maybe I'm biased) when using the pure AMD64 installation.
Speaking of speed; the following are what performance parameters I decided upon after a lot of testing (up to terabyte file sizes, etc.)
# 3ware SATA II 9550SX Controller Settings -
# echo cfq > /sys/block/sda/queue/scheduler \
# Set via Kernel option "elevator=xxx" (in /boot/grub/menu.lst)
# These 3 below are set inside /etc/init.d/rc.local
echo 128 > /sys/block/sda/queue/max_sectors_kb
echo 512 > /sys/block/sda/queue/nr_requests
blockdev --setra 16384 /dev/sda
Executing sync; hdparm -t -T /dev/sda1 ; a couple of times yields these results:
/dev/sda1:
Timing cached reads: 1814 MB in 2.00 seconds = 907.13 MB/sec
Timing buffered disk reads: 442 MB in 3.01 seconds = 146.94 MB/sec
/dev/sda1:
Timing cached reads: 1814 MB in 2.00 seconds = 907.08 MB/sec
Timing buffered disk reads: 434 MB in 3.01 seconds = 144.17 MB/sec
... which is about 50% faster that using the Debian defaults, and about 15% faster than 3Ware's recommended 'deadline' scheduler...
Also please see Section 1.
#2
Posted by sneex on Tue 26 Jun 2007 at 14:09
Of the three 'identical' AMD64 servers, two say interface eth2 is 100MBits:
e100: eth2: e100_watchdog: link up, 100Mbps, full-duplex
eth0: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:47:f9:24
eth1: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:47:f9:25
One states that eth0 is 100MBits:
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
eth0: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:48:31:f0
eth1: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:48:31:f1
Question is 'Why?' Why would Debian 4, using the DVD iso installation method, detect the same hardware differently?
So, after further research I see (for srv0) -
dmesg |grep e100
PCI: Firmware left 0000:03:08.0 e100 interrupts enabled, disabling
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
e100: eth0: e100_probe: addr 0xfeafb000, irq 201, MAC addr 00:E0:81:48:31:E4
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
However for srv1, I see -
dmesg |grep e100
PCI: Firmware left 0000:03:08.0 e100 interrupts enabled, disabling
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
e100: eth0: e100_probe: addr 0xfeafb000, irq 177, MAC addr 00:E0:81:47:F9:96
e100: eth2: e100_watchdog: link up, 100Mbps, full-duplex
(NOTE: The 3rd server was hosed while researching why these first two systems do not agree as to the hardware interface; so it's not reported on this AMD64 Section.)
What I am getting at is this: The hardware is the same but the installer doesn't see the same interfaces. In the long run I guess it doesn't matter. I simply want the 1GBit interfaces to plumb-up to my internal/private routes and the 100MBit interfaces to plumb-up to the public/Internet routes. As I have never seen this behavior before it struck me as a little weird.
In summary -
Server 0:
Processors 4
Model Dual Core AMD Opteron(tm) Processor 280
CPU Speed 2.39 GHz
Cache Size 1024 KB
System Bogomips 19120.69
PCI Devices 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE
00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
01:03.0 RAID bus controller: 3ware Inc 9550SX SATA-RAID
02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
02:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
03:05.0 Mass storage controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller
03:06.0 VGA compatible controller: ATI Technologies Inc Rage XL
03:08.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100]
IDE Devices hda: Slimtype DVDRW SSW-8015S
SCSI Devices AMCC 9550SX-4LP DISK (Direct-Access)
USB Devices Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller
Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller
Server 1:
Processors 4
Model Dual Core AMD Opteron(tm) Processor 280
CPU Speed 2.39 GHz
Cache Size 1024 KB
System Bogomips 19143.52
PCI Devices 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE
00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
01:03.0 RAID bus controller: 3ware Inc 9550SX SATA-RAID
02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
02:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
03:05.0 Mass storage controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller
03:06.0 VGA compatible controller: ATI Technologies Inc Rage XL
03:08.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100]
IDE Devices hda: Slimtype DVDRW SSW-8015S
SCSI Devices AMCC 9550SX-4LP DISK (Direct-Access)
USB Devices Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller
Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller
Looks like the same system, I see the IRQs are different, but would that be enough to cause the 100MHz Ethernet interface show up differently?
e100: eth2: e100_watchdog: link up, 100Mbps, full-duplex
eth0: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:47:f9:24
eth1: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:47:f9:25
One states that eth0 is 100MBits:
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
eth0: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:48:31:f0
eth1: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:48:31:f1
Question is 'Why?' Why would Debian 4, using the DVD iso installation method, detect the same hardware differently?
So, after further research I see (for srv0) -
dmesg |grep e100
PCI: Firmware left 0000:03:08.0 e100 interrupts enabled, disabling
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
e100: eth0: e100_probe: addr 0xfeafb000, irq 201, MAC addr 00:E0:81:48:31:E4
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
However for srv1, I see -
dmesg |grep e100
PCI: Firmware left 0000:03:08.0 e100 interrupts enabled, disabling
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
e100: eth0: e100_probe: addr 0xfeafb000, irq 177, MAC addr 00:E0:81:47:F9:96
e100: eth2: e100_watchdog: link up, 100Mbps, full-duplex
(NOTE: The 3rd server was hosed while researching why these first two systems do not agree as to the hardware interface; so it's not reported on this AMD64 Section.)
What I am getting at is this: The hardware is the same but the installer doesn't see the same interfaces. In the long run I guess it doesn't matter. I simply want the 1GBit interfaces to plumb-up to my internal/private routes and the 100MBit interfaces to plumb-up to the public/Internet routes. As I have never seen this behavior before it struck me as a little weird.
In summary -
Server 0:
Processors 4
Model Dual Core AMD Opteron(tm) Processor 280
CPU Speed 2.39 GHz
Cache Size 1024 KB
System Bogomips 19120.69
PCI Devices 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE
00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
01:03.0 RAID bus controller: 3ware Inc 9550SX SATA-RAID
02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
02:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
03:05.0 Mass storage controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller
03:06.0 VGA compatible controller: ATI Technologies Inc Rage XL
03:08.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100]
IDE Devices hda: Slimtype DVDRW SSW-8015S
SCSI Devices AMCC 9550SX-4LP DISK (Direct-Access)
USB Devices Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller
Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller
Server 1:
Processors 4
Model Dual Core AMD Opteron(tm) Processor 280
CPU Speed 2.39 GHz
Cache Size 1024 KB
System Bogomips 19143.52
PCI Devices 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE
00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
01:03.0 RAID bus controller: 3ware Inc 9550SX SATA-RAID
02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
02:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
03:05.0 Mass storage controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller
03:06.0 VGA compatible controller: ATI Technologies Inc Rage XL
03:08.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100]
IDE Devices hda: Slimtype DVDRW SSW-8015S
SCSI Devices AMCC 9550SX-4LP DISK (Direct-Access)
USB Devices Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller
Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller
Looks like the same system, I see the IRQs are different, but would that be enough to cause the 100MHz Ethernet interface show up differently?
#1
Posted by sneex on Wed 20 Jun 2007 at 15:58
My expedition into AMD64 ...
I recently purchased three identical servers with 2 AMD Opteron 280 dual core AMD64 CPUs, 8GB RAM, and 4 500GB SATA II hard drives (setup in a 3 drive RAID 5 with Hot-spare) each.
I spent a few days running CentOS 5 for AMD64 (after trying to create several 80GB files the 3Ware RAID went into a coma (it froze and lost about 160GB of space) -- between trying to get support through CentOS channels (e-mail/IRC) and the 3Ware vendor itself I abandoned CentOS.)
Well, I since own the 3Ware cards now - plus I feel the 9550SX cards are good RAID controllers - I spent the last two weeks running Debian AMD64 ... which is "officially" AMD64 supported now; but ... um, well, let's say it's not exactly ready for me -- at least not for what I wanted to do anyways ... but I am trying.
Mostly documented here will be my experiences -- the good, the bad, and the OMG! of this new adventure.
[ ... more to come ... ]
-Sx-
-----------
NOTE: These articles will more or less be posted in reverse order; I'm not really sure how to get them in chronological order...
I recently purchased three identical servers with 2 AMD Opteron 280 dual core AMD64 CPUs, 8GB RAM, and 4 500GB SATA II hard drives (setup in a 3 drive RAID 5 with Hot-spare) each.
I spent a few days running CentOS 5 for AMD64 (after trying to create several 80GB files the 3Ware RAID went into a coma (it froze and lost about 160GB of space) -- between trying to get support through CentOS channels (e-mail/IRC) and the 3Ware vendor itself I abandoned CentOS.)
Well, I since own the 3Ware cards now - plus I feel the 9550SX cards are good RAID controllers - I spent the last two weeks running Debian AMD64 ... which is "officially" AMD64 supported now; but ... um, well, let's say it's not exactly ready for me -- at least not for what I wanted to do anyways ... but I am trying.
Mostly documented here will be my experiences -- the good, the bad, and the OMG! of this new adventure.
[ ... more to come ... ]
-Sx-
-----------
NOTE: These articles will more or less be posted in reverse order; I'm not really sure how to get them in chronological order...
[0 Comments
| Add Comment
|
]
]