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

[Michael Paoli]

Remote management of the hardware, if feasible, would be a good   
thing.  E.g. KVM over IP.

I don't see such an option for Rackform iServ R107, but I do see
option for:
IPMI 2.0 Controller
... that might come close (might be quite useful when used, e.g. via
remote Open Source software such as ipmitool - should then be able to
power cycle remotely, change device used at boot remotely, access 
serial port communications (e.g. serial console and GRUB serial
access) remotely, etc. ... but still not a full KVM over IP (no
graphics) and probably can't fully control/reconfigure BIOS remotely).

Many vendors offer some type of KVM over IP (or equivalent), but in
many cases it's an add-on extra cost option, e.g.:
Hewlett-Packard's iLO/iLO2
Dell's DRAC
Sun Microsystem's LOM and RSC
etc.

There are also external management devices for doing KVM over IP
(e.g. Avocent(/Cyclades - Avocent acquired Cyclades).  Some
advantages with such an external device, is often such units can
control multiple systems, consistent interface (rather than a
different interface and method for each vendor's own solution),
typically only requires one IP address for managing multiple systems,
and being a separate external device, one avoids add-on costs on a
per-unit basis when purchasing/replacing systems (particularly when
their equivalent options are an add-on cost with each system
purchased).  Also, in at least some cases, these external management 
devices also include other management capabilities - i.e. remote  
power management, and also not just KVM over IP, but also serial
terminal server capabilities - again, securely, and remotely.  

Hmmmm, ... come to think of it, I know someone who used to be a quite
regular attendee of the Berkeley Unix User Group
(http://www.buug.org/) and went to work for Cyclades (now Avocent).
I wonder if Avocent has a "user group" program or might like to
donate (or at least provide at deep discount on) such a device for
SF-LUG to review? (and keep) :-)  I'll see what I may be able to turn
up.

There are also other various interesting products/solutions out 
there, e.g. I just found this one:
http://www.realweasel.com/
Not quite KVM over IP, but serial port access to keyboard and VGA
text - could be quite useful when combined with a terminal server.


Quoting jim stockford <jim at well.com>:

>     here're the specs for the new box, which is on its
> way (shipped 9/13):
> 
> 1.  1   Rackform iServ R107
>      Details:
>      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) - 
> Integrated
>      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 
> Cache,NCQ) SATA
>      Fixed Drive - 2:  250GB Seagate Barracuda ES (3Gb/s,7.2Krpm,16MB 
> Cache,NCQ) SATA
>      Rail Kit:  2-Piece Sliding Rail Kit
>      OS:  None
>      Warranty: Standard 3 Year - Return to Depot - Advanced Component 
> Exchange
>      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
> list.
> 
>     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.