Re: remote management
On May 14, 2013, at 7:55 PM, Devin Reade g...@gno.org wrote: The AdderLink can be a bit expensive for small businesses and hobbiests in their recommended one-per-server configuration (approx USD 500), however if you don't have to have different access levels for different servers' consoles, and can put up with accessing the console of only one server at a time, then you can amortize this cost by putting a decent non-networked (but electronic) KVM switch between the AdderLink and multiple servers. That price also seems comparable to similar types of technology. And for the record, the DLink DKVM-8E does *not* constitue a decent KVM switch; it's crap. It looks like AdderLink have DVI/HDMI versions of the iPEPS available, too, although I've not used them. Besides using encrypted network traffic and supporting a small number of login accounts, the AdderLink offers rudimentary source-IP-based access control. It's still a good idea to use a segrated admin subnet if you can, just on general principles. I can second the AdderLink's. I've only got the VGA versions, as well, but will be getting the DVI/HDMI in the net purchase, whenever that happens. The mouse can be funky at times, but it's easily fixed. Sometimes the calibration doesn't work as expected. But it's better than running to another building and whipping out a crash cart. :-) Sean PS Yes, a second, segregated admin subnet is a good thing (for a variety of reasons).
Re: remote management
On 2013-05-13, Tony Berth tonybe...@googlemail.com wrote: Dear Group, I would like to know what kind of environment you use for remote management of one or more openbsd servers. serial console servers and remote controllable power bars. Which KVM over IP solution would you recomend. I don't generally use KVM/IP, but occasionally had reason to use dell idrac enterprise which works OK (the java client is a bit annoying at times but workable). N.B. shared IPMI/LAN ports generally do *not* work on OpenBSD (intentionally).
Re: remote management
On 5/14/2013 3:23 PM, Stuart Henderson wrote: On 2013-05-13, Tony Berth tonybe...@googlemail.com wrote: Dear Group, I would like to know what kind of environment you use for remote management of one or more openbsd servers. N.B. shared IPMI/LAN ports generally do *not* work on OpenBSD (intentionally). FWIW the IPMI + Intel PRO/1000 MT (82574L) shared port on these boards works great: http://www.supermicro.com/products/motherboard/Xeon/C202_C204/X9SCL-F.cfm I was even able to use the IPMI-provided virtual CDROM drive to do the initial install from an ISO located on my desktop PC. OpenBSD 5.3 (GENERIC.MP) #62: Tue Mar 12 18:21:20 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8560050176 (8163MB) avail mem = 8309690368 (7924MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb4c0 (55 entries) bios0: vendor American Megatrends Inc. version 2.0b date 09/17/2012 bios0: Supermicro X9SCL/X9SCM acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SPMI SSDT SSDT EINJ ERST HEST BERT acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) P0P1(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) GLAN(S4) EHC1(S4) EHC2(S4) HDEF(S4) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E31240 @ 3.30GHz, 3300.47 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 100MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E31240 @ 3.30GHz, 3300.03 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E31240 @ 3.30GHz, 3300.03 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E31240 @ 3.30GHz, 3300.03 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU E31240 @ 3.30GHz, 3300.03 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu4: 256KB 64b/line 8-way L2 cache cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Xeon(R) CPU E31240 @ 3.30GHz, 3300.03 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu5: 256KB 64b/line 8-way L2 cache cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Xeon(R) CPU E31240 @ 3.30GHz, 3300.03 MHz cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu6: 256KB 64b/line 8-way L2 cache cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Xeon(R) CPU E31240 @ 3.30GHz, 3300.03 MHz cpu7: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu7: 256KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24
Re: remote management
--On Monday, May 13, 2013 09:24:13 PM +0200 Tony Berth tonybe...@googlemail.com wrote: I would like to know what kind of environment you use for remote management of one or more openbsd servers. Which KVM over IP solution would you recomend. For OpenBSD I usually try to have hardware with a decent serial console or integrated OOB mechanisms like the Sun ALOMs. (Those that use a *different* ethernet jack than that used by the OS.) If I am forced into a situation that mandates a KVM type of setup, then one solution that has worked well for me is the AdderLink iPEPS http://www.adder.com/products/adderlink-ipeps or iPEPS-DA http://www.adder.com/products/adderlink-ipeps-da. One nice thing about the AdderLink products is that they use the commercial RealVNC (encrypted) for remote management so that you're not faced with having to do something annoying like starting MS-Windows in a VM just to be able to run the tools to access your remote servers. (Yes, I'm looking at you, VMWare.) (And you other remote management solutions that need windows-specific clients.) The AdderLink can be a bit expensive for small businesses and hobbiests in their recommended one-per-server configuration (approx USD 500), however if you don't have to have different access levels for different servers' consoles, and can put up with accessing the console of only one server at a time, then you can amortize this cost by putting a decent non-networked (but electronic) KVM switch between the AdderLink and multiple servers. That price also seems comparable to similar types of technology. And for the record, the DLink DKVM-8E does *not* constitue a decent KVM switch; it's crap. It looks like AdderLink have DVI/HDMI versions of the iPEPS available, too, although I've not used them. Besides using encrypted network traffic and supporting a small number of login accounts, the AdderLink offers rudimentary source-IP-based access control. It's still a good idea to use a segrated admin subnet if you can, just on general principles. Devin
remote management
Dear Group, I would like to know what kind of environment you use for remote management of one or more openbsd servers. Which KVM over IP solution would you recomend. Thanks Tony
Re: remote management
On 05/13/2013 03:24 PM, Tony Berth wrote: Dear Group, I would like to know what kind of environment you use for remote management of one or more openbsd servers. Which KVM over IP solution would you recomend. Oh, I remember those. Last IP KVM switch I used worked BETTER for OpenBSD than it did for Windows... Seriously. Windows desktop was a garbled mess, looked like a badly tuned TV set (for those that remember when you could and needed to tune TVs), but running OpenBSD with X, it Just Worked. Go figure. Getting the client software to run was another matter all together, as I recall, it was a horribly Windows/IE dependent. Really, though. If it's in a data center, usually I just use the remote access controller on most servers these days or a serial console. Just remember... if you got a big *** lock on the data center door (you should), make sure your remote console (however you do it) is comparably secure. Putting your remote access on the same network as all your users is similar to removing the locks on the data center door. Not changing the default RAC password and/or IDs is like putting a Welcome mat under the (unlocked) door of the data center. And ask yourself...why do you run OpenBSD? Maybe because of the security. What OS do you think is at the base of your IP KVM? Probably not OpenBSD. Strength of a chain is the weakest link and all that -- if someone can knock over your KVM, they own your box. Don't compromise your machine with a bad remote console. Nick.
Re: remote management
thanks for the prompt replies. Any recommendation for IPMI cards and KVM over IP switches that work well with openbsd? Tony On Tue, May 14, 2013 at 12:07 AM, Nick Holland n...@holland-consulting.netwrote: On 05/13/2013 03:24 PM, Tony Berth wrote: Dear Group, I would like to know what kind of environment you use for remote management of one or more openbsd servers. Which KVM over IP solution would you recomend. Oh, I remember those. Last IP KVM switch I used worked BETTER for OpenBSD than it did for Windows... Seriously. Windows desktop was a garbled mess, looked like a badly tuned TV set (for those that remember when you could and needed to tune TVs), but running OpenBSD with X, it Just Worked. Go figure. Getting the client software to run was another matter all together, as I recall, it was a horribly Windows/IE dependent. Really, though. If it's in a data center, usually I just use the remote access controller on most servers these days or a serial console. Just remember... if you got a big *** lock on the data center door (you should), make sure your remote console (however you do it) is comparably secure. Putting your remote access on the same network as all your users is similar to removing the locks on the data center door. Not changing the default RAC password and/or IDs is like putting a Welcome mat under the (unlocked) door of the data center. And ask yourself...why do you run OpenBSD? Maybe because of the security. What OS do you think is at the base of your IP KVM? Probably not OpenBSD. Strength of a chain is the weakest link and all that -- if someone can knock over your KVM, they own your box. Don't compromise your machine with a bad remote console. Nick.
