[sf-lug] SF-LUG 2007-09-17 meeting & SF-LUG.COM replacement box (& BALUG)

jim stockford jim at well.com
Sat Sep 15 12:29:33 PDT 2007

    here're the specs for the new box, which is on its
way (shipped 9/13):

1.  1   Rackform iServ R107
     CPU:  Intel Xeon X3210 2.13GHz Quad-Core - 8MB L2 Smart Cache 
1066MHz System Bus
     RAM:  2GB (2 x 1GB) Unbuffered ECC DDR2-667
     NIC:  Dual 10/100/1000 Mbps NICs (Intel 82573L + 82573V) - 
     Management:  None
     PCI Riser Options:  PCIe (For PCI-X Options, Please Contact our 
Sales Department)
     PCIe x8:  None
     Fixed Drive - 1:  250GB Seagate Barracuda ES (3Gb/s,7.2Krpm,16MB 
     Fixed Drive - 2:  250GB Seagate Barracuda ES (3Gb/s,7.2Krpm,16MB 
     Rail Kit:  2-Piece Sliding Rail Kit
     OS:  None
     Warranty: Standard 3 Year - Return to Depot - Advanced Component 
     Notes:  They will be doing SW RAID

    Well, we have the box itself, which brings to mind
our having another colo visit.
    I hadn't tho't about dual NICs. I have one or two
lying around we might be able to use.
    remote KVM i believe is a function of does the box
support it and does the colo support a compliant
console server, yes?
    each box in the colo connects to 110VAC power
via a standard receptacle in the rack, and each
receptacle is controlled by the colo. they support
power cycling via their staff, don't know of client
access to that facility.
    looking at the above spec, it looks like CD or
DVD is not in the box. if true, then we may need a
stand-alone CD-DVD player-recorder device.
    I vote that we take a look at the box when it gets
here, all are welcome to join the inspection. If the
box features are really inconvenient, maybe I can
negotiate getting it upgraded. I'm willing to buy the
necessary extra stuff for us to pop in, if that's the
way to go.
    loading a DVD in the box ready to restore or
otherwise fix is a good idea, just need to be sure
it doesn't take off upon power recycling, right?
    note that the policy for the new box will be
different from that which is in place now. We'll
not have everybody-welcome shell accounts,
but shell accounts only for people administering
the box in some way. Also, we need to update the
list of people with emergency access to the box
itself. the colo allows three names on its access

    Credit due: "the colo" is ColoServe, aka ServePath.
Note that they survived the recent downtown power
loss when other, similar facilities did not.

On Sep 15, 2007, at 11:49 AM, Michael Paoli wrote:

> So, new box(es) ..
> For the SF-LUG 2007-09-17 meeting, can we round up myself, Jim 
> Stockford,
> and Nathan?  If we can round up the "core" systems administrators of
> the sf-lug.com. box, we could include doing a "planning meeting" for
> the new box(es) at the SF-LUG 2007-09-17 meeting.
> Also, do we have more details on the new/replacement hardware?  E.g.
> make, model, configuration/specifications, etc.?  (Do we even have 
> those
> details on the existing sf-lug.com. hardware?).  Do we know if both
> boxen have an additional Ethernet interface available (e.g. to set up
> private direct connection between the boxes, to be able to transfer 
> lots
> of data relatively quickly - and also quite securely)?  Can we get 
> remote
> KVM (not just serial console) access to these systems?  Also having 
> remote
> power control would be good too (but in a pinch, colo can generally 
> handle
> powering devices off and on ... some even have facilities to allow that
> without  physically touching the hardware ... and some may even allow 
> that
> to be controlled by the clients via software).
> CDs/DVDs ... should we have/leave some suitably appropriate "recovery"
> CD/DVD in the boxen, so that with remote KVM access, if/when recovery,
> troubleshooting, etc., may be needed, we'd have a most appropriate
> media already in the box and ready to boot from (with possible change
> first to the boot configuration).
> Quoting jim stockford <jim at well.com>:
>> very helpful, thanks!
>> On Aug 30, 2007, at 6:38 AM, Michael Paoli wrote:
>>> Well, treat replacing the sf-lug.com box as an "upgrade".
>>> ... basically all the data stays the same - or as same as feasible,
>>> or at *least* fully back up all the data and metadata, so all the
>>> applicable desired functionality and data can be restored and
>>> put back in place as soon as feasible.
>>> May also be quite desirable to tweak the filesystem configuration and
>>> mirroring a bit when doing the "upgrade" ... most notably, I know
>>> there's
>>> been desire to set up the disk mirroring to be quite symetrical - at
>>> present I don't think it's quite as symetrical as desired.  Some of
>>> the filesystem heirarchy should also be split a bit more into 
>>> separate
>>> filesystems, ... most notably I'd strongly recommend /usr and /var
>>> be separate filesystems.  I'd also recommend /tmp be tmpfs.
>>> Among the metadata, also gather size and sizing information (e.g.
>>> du -sx /var; du -sx /usr; sfdisk -uS -l; sfdisk -uS -d).
>>> references/excerpts:
>>> $ hostname; df -k /var /usr; mount | awk '{if($3=="/tmp")print;}'
>>> sf-lug
>>> Filesystem           1K-blocks      Used Available Use% Mounted on
>>> /dev/md0               9612516   3323336   5800888  37% /
>>> /dev/md0               9612516   3323336   5800888  37% /
>>> /dev/hda9 on /tmp type ext3 (rw)
>>> $
>>> Quoting jim stockford <jim at well.com>:
>>>>     it looks like we're getting a replacement box,
>>>> which means revisiting box issues, notably
>>>> hostname and the install-configs of the various
>>>> apps on the box (notably postfix and apache).
>>>>     comments and opinions are welcome.
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug

More information about the sf-lug mailing list