Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Tools For Managing Multiple Serial Console Servers?

timothy posted about a year ago | from the many-roads-to-rome dept.

Virtualization 104

An anonymous reader writes "I've recently been charged with updating our existing serial console access tools. We have 12 racks of servers each with a console server in it (OpenGear, ACS, and a few others). Several of these systems host virtual machines which are also configured to have 'serial' management (KVM, virt serial). In total it comes to about 600 'systems.' All the systems also have remote power management (various vendors). Right now our team has a set of home grown scripts and a cobbled together database for keeping this all together. Today any admin can simply ssh into the master, run 'manage hostname console' and automatically get a serial console or run 'manage hostname power off' to cut the power to a system. I'd rather use some tools with more of a community than just the 4 of us. What tool(s) should I move my group onto for remote serial/power management?"

Sorry! There are no comments related to the filter you selected.

How about SourceForge? (4, Insightful)

Havokmon (89874) | about a year ago | (#45358887)

If you published your tools, you might find you're not the only ones who need the flexibility you've written into your toolset.

Re:How about SourceForge? (1)

swalve (1980968) | about a year ago | (#45364481)

What does "a community" have to do with whether the tools work or not?

Re:How about SourceForge? (1)

Havokmon (89874) | about a year ago | (#45367271)

What does "a community" have to do with whether the tools work or not?

To Quote - " I'd rather use some tools with more of a community than just the 4 of us."
He also never said that there were shortcomings in the toolset they created. It sounds like he may not like the database, maybe he wants a nicer front-end for managing the tables? But it's not described as 'the problem'.

Therefore, if they create a community around their own toolset, then the only problem actually described in the OP is resolved.

Re:How about SourceForge? (1)

The_Revelation (688580) | about a year ago | (#45365729)

HEY! HEY! We want flexible tools, not a bunch of malware! Consider hosting your own FTP?

Re:How about SourceForge? (1)

wonkey_monkey (2592601) | about a year ago | (#45366473)

Well, maybe not SourceForge [slashdot.org] specifically, but yeah.

Switch to a cloud system ... (0)

Skapare (16644) | about a year ago | (#45358905)

... like OpenStack. Then you have access to everything.

Re:Switch to a cloud system ... (0)

Anonymous Coward | about a year ago | (#45359009)

Yep, throw everything out and buy all new from a single vendor.

Good plan I'm sure they have the money for that.

Re:Switch to a cloud system ... (0)

Anonymous Coward | about a year ago | (#45359087)

Yep, throw everything out and buy all new from a single vendor.

Good plan I'm sure they have the money for that.

OpenStack's free and OpenSource, but if he's looking for BIOS level on the hosts then he's stuck in the same situation.
Personally, I use CloudStack and IPMI on hosts, managment, and storage...

Re:Switch to a cloud system ... (1)

Skapare (16644) | about a year ago | (#45360845)

IPMI can certain help at the hardware level. But if you need frequent hardware level access, or access to it by more than a couple people, something is wrong. The cloud infrastructure allows appropriate virtual level access (terminate an instance and start a new one). Maybe his "community access" was meant to do OS installs, which an infrastructure cloud stack would do. If not, maybe we need to know what the OP is really wanting to do.

Re:Switch to a cloud system ... (0)

Anonymous Coward | about a year ago | (#45362465)

Depends on the device and scenario, I'm looking for something similar for switches/routers.

Cloud based and even local IP/LAN based don't do me any good when the switches that inter-connects it all is the one I need access to.

Right now I have a port and re-patch to whatever device I want to attach to. I'm looking into getting adapters to connect to our avocent setup but that doesn't let me copy/paste config output from my desktop.

Re:Switch to a cloud system ... (1)

Skapare (16644) | about a year ago | (#45359363)

Use the current host hardware.

Raritan. (0, Offtopic)

Anonymous Coward | about a year ago | (#45358935)

Raritan motherfucker! Do ya Speak it!?

Why? (5, Insightful)

Anonymous Coward | about a year ago | (#45358937)

You haven't identified any missing features or existing anti-features in your current toolset.
The only hint of anything wrong with your setup is "I'd rather use some tools with more of a community than just the 4 of us."

Q: What tool(s) should I move my group onto for remote serial/power management?
A: Yours. Clean the tools up, open source them, and market them. Your community will grow.

Murder + Sell Organs + Buy hardware (0)

Anonymous Coward | about a year ago | (#45358939)

Step 1: Murder the idiot who thought saving 50$ up front while costing 5000$ in the mid term was a good idea
Step 2: Sell his organs on the black market
Step 3: Buy enough of whatever you have the most of to have one system

Good luck.

Try Digi (1)

Anonymous Coward | about a year ago | (#45358949)

You might look at Digi.

I've used their stuff and it works well.

Conman and Powerman (5, Informative)

decepetion (632646) | about a year ago | (#45358973)

Re:Conman and Powerman (1)

trandles (135223) | about a year ago | (#45359107)

Seconded. I use these every day.

Re:Conman and Powerman (1)

Troy Baer (1395) | about a year ago | (#45359247)

Thirded. Conman & powerman rock.

Re:Conman and Powerman (1)

Pedahzur (125926) | about a year ago | (#45360513)

Fourthed; again, use almost every day. Conman and powerman are great.

Conman: Serial consoles, IMPI serial consoles, write your own wrapper if one doesn't exist.
Powerman: Can control just about everything out there. Again, write your own if it doesn't exist. Can even "manage" power on a VM host. You might have to write your own wrapper though (basically a remote shell that runs virsh commands). I know we have a script here, but I don't think I'm allowed to put it in public. It uses rsh to connect to the VM host (KVM) and then runs virsh domstate for power status, and virsh start/virsh destroy for on and off.

Re:Conman and Powerman (0)

Anonymous Coward | about a year ago | (#45359869)

Why was this modded "funny"?

Conserver is your answer (3, Funny)

Anonymous Coward | about a year ago | (#45358977)

I would recommend a look at http://conserver.com/

Re:Conserver is your answer (3, Insightful)

TheCarp (96830) | about a year ago | (#45359229)

I actually was about to post that....with one caveat: Look carefully at versions

Admittedly I haven't worked with conserver since 2005, but it was solid then and I can't imagine it has changed much since. The last time I grabbed it, I found that the source had forked a couple of times and the name "conserver" actually refered to 2 or three different versions of the same program, each with slightly different feature sets.

Few things are more frustrating than trying to figure out why a program isn't working because you are reading the docs for the wrong one.

That said, the conserver we ended up using was simple, lightweight, and did exactly what we wanted.... provide named console access from a single place.

Re:Conserver is your answer (1)

tbuskey (135499) | about a year ago | (#45363719)

Conserver is great. I've used it to monitor Linux consoles after boot (via grub handoff to serial console). Serial consoles are cheaper per port then KVM port and you have a log you can grep.

I've also used it to monitor several consoles going to embedded devices. The users could take over when a coworker had gone on vacation w/o calling the sysadmin.

Conserver (4, Informative)

Anonymous Coward | about a year ago | (#45358981)

At a previous shop i worked we ran conserver against about 1k machines, some virtual but the big bulk of them was physical.

I also implemented a standardized way to control power on/off/reset on those machines as a patch to conserver. Those patches can be found at https://github.com/glance-/conserver/

Re:Conserver (0)

Anonymous Coward | about a year ago | (#45359221)

Then I should say thank you. Actually been using those patches over here as well with great success.

Don't "fix it" (0)

Anonymous Coward | about a year ago | (#45358999)

if it ain't broke don't fix it!

Uplogix (1)

tthomas48 (180798) | about a year ago | (#45359021)

My company builds a replacement (http://uplogix.com), smarter version of a serial console. They can all be managed by web UI and you can term directly into each device, keep configuration on them, and keep each device mapped to its outlet on the power controller. We even have a virtual version that runs on vSphere. You can hook up all the ports via telnet and keep your existing term server, but getting the benefits of the rich CLI and web UI.

Sounds like a perfect use case for you.

Re:Uplogix (1)

h4rr4r (612664) | about a year ago | (#45359225)

WebUI? WHY IN THE NAME OF THE FSM would any sysadmin want that?

People who want serial console access are not looking for "teh shiny".

handle any fan hit anywhere, anytime (1)

raymorris (2726007) | about a year ago | (#45359377)

A web UI means I can handle an issue from any device - a computer in a hotel, grandma's cell phone, whatever.

Also, with many systems, a UI to navigate groups of systems can be handy.

Re:handle any fan hit anywhere, anytime (1)

h4rr4r (612664) | about a year ago | (#45359469)

Just use SSH. You can even keep a copy of a client for most OS with you.

I see you didn't read a word before replying (1)

raymorris (2726007) | about a year ago | (#45360813)

I see you didn't bother to read one word of my post before replying.
Does the computer in the hotel business center have ssh installed? No. Does a borrowed phone have ssh? No.

Ssh is great, until I run out of battery.

Re:I see you didn't read a word before replying (1)

h4rr4r (612664) | about a year ago | (#45360969)

A thumb drive does not need batteries.
You can use an ssh client without installing it from a thumbdrive.

You can install a free ssh client on that phone.

When I am on call I always carry my charged external battery pack.

try that and tell me how it works (1)

raymorris (2726007) | about a year ago | (#45362805)

Try running some random executable from a thumb drive on a hotel computer and tell me how will that works.

Then the next person you see, ask them if it's okay for you to install weird "hacker" apps on their phone

Re:try that and tell me how it works (1)

h4rr4r (612664) | about a year ago | (#45369399)

I do not work from either of those. Do you really trust neither have key loggers installed?

Re:I see you didn't read a word before replying (1)

muridae (966931) | about a year ago | (#45363701)

A thumb drive does not stop the hotel computer from having a key logger, unless you check the cables and boot into a secure OS. I spotted a physical one attached while traveling (New Jersey, Pennsylvania? somewhere up the east seaboard between Boston and DC). Was hard trying to stop my family from making a hotel reservation over a hotel's computer (that one was booked, trying to reserve a room 50 miles down the road) without screaming "because the computer is bloody compromised and that little box could be catching your credit card number!". Pity the hotel didn't care, and I was, by that point, too exhausted to care either. For all I know, it's still there.

Re:I see you didn't read a word before replying (1)

muridae (966931) | about a year ago | (#45363613)

So, wait, you replace SSH on a known secured computer (at least I hope an admin's travel computer is relatively secured) with a web UI? So you can use it from a adware, spyware filled device like a hotel lobby computer or grandma's cell phone filled with spying, keylogging games? Sure, the web UI might be over HTTPS, but that does nothing about spyware seeing you punch in the URL, then type in your username and password. I really hope your IDS knows when you are traveling, and will use the website, and when you are in the office.

I'm required by my hat to ask which hotel you are planning to stay at next, so I can get to the lobby computer a day ahead. Though the last time I spotted a USB keylogger and pointed it out to the hotel staff, they just looked at me cross-eyed and wondered why it mattered.

good point. retracted. For not security sensitive (1)

raymorris (2726007) | about a year ago | (#45364679)

That's a good point and I retract my comment in the context of console servers.

The point I had in mind is that although I use CLI for almost everything, sometimes a GUI is much nicer. The CLI for LSI RAID cards comes to mind.

Re:good point. retracted. For not security sensiti (1)

muridae (966931) | about a year ago | (#45368477)

Locally, sure. Heck, dropping a UI in front of the scripts that the article was asking about might make the management of the variety of devices easier; Just toss together a python program, or other easy language at hand, with the ability to call bash scrips and the ability to throw up a UI and mess with the database that tracks all the devices and their login details; that would make their scripts more usable should they all get fired tomorrow and the new team has access to an easier work flow.
But remote access from a physically unsecured device to what are probably secured systems without rolling one-time-use passwords? I'm just a CS drop out, and I can spot some major security problems there. And yes, I see even remote access to the switches as a problem, since havok could be caused. Imagine copying credentials, then (if it's a smart switch or other smart device) using that to tunnel to the companies boarder router (I recall some Cisco hardware had the ability to go from it's terminal to the terminal of other Cisco devices it was connected to...could be a faulty memory, my CCNA and other stuff expired 10 years ago) and then telling your gateway (from the inside at this point) to ignore the IDS and firewall. Or terminal jump to the IDS/firewall or database and see what other credentials could be had. Heck, I'd demand a VPN from a secure(ish) computer before allowing access to a GUI or CLI...preferably one with an onscreen, randomized keyboard for credential input or crypto signature credentials and a one-time-password (SecurID or something like it). But a public computer with gods know what running on it? Even copying crypto signatures from a thumb drive would be dangerous if the right malware was paying attention; or the malware could just infect the thumb drive. And if BadBIOS turns out to be real and is infecting any usb storage device then that thumb drive with a signature would have to be a single use device, never allowed to touch a secure machine again. A bootable write only (cd or dvd) with a on-screen randomized keyboard, and the public cryto sig burned with it, and a OTP device might be away to use an unsecured computer. Might, I haven't thought, yet, on ways I could still get the info if said machine was in my physical possession and I had hardware logging devices; maybe just recording the screen and network feed would get close, but the OTP device would be a stumbling block. If it used a weak chain, and you used the key at predictable intervals (so I could get multiple "key @ X time") to feed into a rainbow table...tricky, but maybe, I'll have to ponder more.

And don't take my security concerns as a personal thing. I'm just brainstorming so if the article author reads these posts, they might get to thinking about further issues and why those local CLI scripts might not be so bad. Or someone else thinking about remote access might question their security protocol.

Re:I see you didn't read a word before replying (1)

tbuskey (135499) | about a year ago | (#45363767)

If you're using the computer in the hotel business center to get console access, you probably don't care about security. If you care about security at all, you're going to use your own device.

Re:handle any fan hit anywhere, anytime (1)

Sique (173459) | about a year ago | (#45359471)

Web UIs suck if you have to mass deploy something. CLIs are predestined for such jobs.

Re:Uplogix (2)

tthomas48 (180798) | about a year ago | (#45359379)

The advanced CLI is for the sysadmin. The WebUI allows you to lock down users to say 1 port on a machine and give them a nice shiny button to click on.

Re: Uplogix (0)

Anonymous Coward | about a year ago | (#45368679)

people who's ONLY response is "Why would you wanna do that?" are not going to have an answer to your question. Hell, they don't even have a good imagination. They are excellent robots though, and can be used for assembly line work.

if it ain't broke... (5, Insightful)

tudorxpopescu (2595289) | about a year ago | (#45359023)

So... let me get this straight, you have a system which is easy to use and works just fine, and is written in house. Obviously, you want to change it... because? Jeez.

Re:if it ain't broke... (3, Informative)

rnturn (11092) | about a year ago | (#45359157)

My thought exactly. Unless they expect their console access needs to explode soon and the current system cannot scale, I can't see the need to change. The existing crew knows how to use the current setup and surely no more than a couple of pages of documentation would be all that's needed for any newcomer to come up to speed. Switching to a 3rd-party console access tool will just be one more thing that'll wind up appearing on the job adverts for new administrators and one more thing that'll slow down the hiring process when the HR filtering software doesn't see `ConsolePro2013++ Gold' on a candidate's resume.

Or did Management issue an edict of "Buy Not Build"?

Re:if it ain't broke... (1)

Princeofcups (150855) | about a year ago | (#45359313)

My thought exactly. Unless they expect their console access needs to explode soon and the current system cannot scale,

Agreed. Standardization should decrease complexity (of maintenance), not increase it. Keep the tools as simple as possible, and as close to vendor standard as possible. It's like admins who customize root. If you leave it generic, then every admin knows what to expect.

Re:if it ain't broke... (1)

ArsenneLupin (766289) | about a year ago | (#45360099)

It's like admins who customize root. If you leave it generic, then every admin knows what to expect.

... and every intruder too!

Re:if it ain't broke... (1)

bobbied (2522392) | about a year ago | (#45360475)

Now *how* would an intruder get root?

Sarcasm, aside...

There are benefits to keeping things standard and as long as you implement reasonable security configurations and don't allow non-local root logins, I don't see any real reason to change root in most cases. Your life (and the lives of admins to come behind you) will be much easier.

Re:if it ain't broke... (2)

TheCarp (96830) | about a year ago | (#45360477)

I completely agree except for one thing.... and I am looking at YOU redhat..... if the system default that they come to expect is that ls output is unreadable due to dircolors being the distribution default which assumes a light colored background.... that should be fixed with extreme prejudice.

Re:if it ain't broke... (1)

mu51c10rd (187182) | about a year ago | (#45361703)

when the HR filtering software doesn't see `ConsolePro2013++ Gold' on a candidate's resume.

Hmmm...and I am only experienced with ConsolePro2011++ Gold...time to upgrade the skillset...

Re:if it ain't broke... (1)

muridae (966931) | about a year ago | (#45363737)

Be glad you skipped ConsolePro2012+++ Platinum. It was utter garbage.

Re:if it ain't broke... (0)

Anonymous Coward | about a year ago | (#45359185)

We had this constantly where I used to work. We had a whole load of in house admin tools that were perfectly customized to our environment but some PHB insisted on replacing them all with commercial products that didn't work so well with the reasoning of ' who will support the in house tools if you all leave'. Turns out what he really meant was 'who will support the in house tools if I outsource you all'.

Re:if it ain't broke... (0)

Anonymous Coward | about a year ago | (#45359219)

As a user of a similar system which was easy to use, worked just fine, and was written in-house, the problem has been that it is used as a vehicle for turf building.

"Oh that sucks, we'll rewrite it to our own specifications and we won't let you know we were rewriting it for 6 months. Please deploy this onto your production system and enjoy the crashes, out-of-memory situations, and 100% cpu consumption we have now introduced."

If only they did not choose a Nordic name for their tool.

Re:if it ain't broke... (1)

Joining Yet Again (2992179) | about a year ago | (#45359493)

Because virtual server cloud crap is all about resume buzzwords, brah.

It doesn't matter if you've produced an excellent in-house solution, because THAT DOESN'T GET YOU A JOB ELSEWHERE. Much better to switch to something which'll end up with your spending 50% of the original time adapting to the new system, and another 80% implementing all the missing features.

Re:if it ain't broke... (1)

sl4shd0rk (755837) | about a year ago | (#45359859)

Obviously, you want to change it... because? Jeez.

I think OP is trying to address the issue of having an infrastructure running on a bunch of home grown stuff supported by just a couple guys. If it works, great but when one or two or three of those guys leave, all of a sudden nobody knows how the thing works and you have a mess. If there is a mandated documentation ritual along with revision control, it helps, but that's probably not the case. OP is wondering if there is an open source solution out there already doing what they've duct-taped together. In my dealings with KVM, I'm guessing not. It's a great question to ask now rather than later.

Re:if it ain't broke... (1)

Gothmolly (148874) | about a year ago | (#45360051)

No kidding. Large enterprises are built from cobbled together scripts and databases.

Are you willing to monoculture your vendors? (3, Informative)

tlambert (566799) | about a year ago | (#45359029)

Are you willing to monoculture your vendors?

If the answer is "no", then you are stuck with your home-grown stuff. Vendors intentionally introduce incompatibilities to lock you into using only them, so you aren't going to find some project that provides a HAL, or at least not one that will live through the next software update from one of your vendors.

You should also be aware (I'm sure you are, if you understand the dynamics of your scripts, but some reading this probably aren't) that some systems won't negotiate a KVM style console unless they are selected active in the KVM prior to boot, so there's an interaction between your power management sequencing and the virtual serial and real serial, and that varies from vendor to vendor and software update to software update.

If you are also using Real KVM(tm) style virtual video consoles, you're probably already aware that Linux and most other Open Source OS's fail to negotiate EDID information correctly, unless you use the closed source video drivers, unless they are selected as the active input on the virtual/real video display device, since those implementations are usually not multithreaded, and so if you have 4 HDMI inputs, and #2 is selected, and #4 is where the device is that comes up and does it's one-time negotiation (this is what's broken about the OS drivers: they should retry periodically until they get a response, then echo up the response to the video driver, which if it's in X/Wayland in user space, it's not going to happen, since it only happens at startup) you are SOL. So your scripts probably have that knowledge, too. Not that it'll do you any good if you have a Linux box on the second input on a physical Samsung monitor, mind you, as they automatically switch away from inactive inputs, and default tho the first input if there are none active.

So good luck with your ask, unless you are willing to start your own project, and are willing to push to get UEFI, u-boot, Linux/BSD video drivers, and other things fixed as part of the project overhead.

Re:Are you willing to monoculture your vendors? (1)

h4rr4r (612664) | about a year ago | (#45359253)

WTF are you talking about?

There are plenty of open source tools that can support lots of vendors. Conman is just the first one I thought of.

By KVM he means Kernel Virtual Machine not Keyboard Video Mouse.

Good lord (0)

Anonymous Coward | about a year ago | (#45359057)

Why are you looking for work to do? Your system is proprietary; your vendor mix and use cases are unique to your "community" and it works, so why the fuck do you want to reinvent it with a system that is not specific to your needs?

If you want to re-do it the "right" way you will pick one vendor, replace all of your non-compliant stuff with their hardware, and then fully adopt their toolset. Of course this is only "right" in the eyes of that vendor. Since you have your own right way, stop looking for a different one and go fix something else.

obligatory RasPi post (0)

Anonymous Coward | about a year ago | (#45359065)

Want to do it cheap?

A raspberry pi has a serial input and enough GPIO's to externally switch it to many different devices.

the Beaglebone Black probably has much more potential in this regard as it has many serial ports and the switching could switch all of them at once to a new set of ports giving a much higher number of potential devices.

Re:obligatory RasPi post (0)

Anonymous Coward | about a year ago | (#45360539)

Oh lord... Raspberry PI solution? Seriously?

Don't get me wrong, I love the Pi but what you are suggesting doesn't fix the poster's problem and is pretty much NUTS.

rtty, old school technology (5, Informative)

Above (100351) | about a year ago | (#45359081)

There's a little known, but very useful program called rtty. You can find it at ftp://ftp.isc.org/isc/rtty/rtty-4.0.shar.gz. Yes, it was last updated in 2003. Yes, there are package for major open source distributions.

Here's serial consoles on the cheap:

Buy multiport USB to Serial devices. They are a USB hub with a bunch of USB to Serial adapters hung off of them. Here's a 16-porter for an example: http://www.startech.com/Cards-Adapters/Serial-Cards-Adapters/~ICUSB23216F

Hang them off a low end box, I like half-depth Intel Atom servers with lots of USB ports.

Run rtty. It records each console to a log file 24x7, and allows multiple people to connect at the same time (including typing).

Re:rtty, old school technology (1)

bobbied (2522392) | about a year ago | (#45360619)

Problem with this is that every time you plug in a new USB device, you are likely to totally hose the device names on the next reboot. It is *really* hard to tell what order your USB devices will be initialized and in this case it will be a serious issue trying to sort out what port is which every time you want to add or remove a device.

Re:rtty, old school technology (1)

profplump (309017) | about a year ago | (#45360799)

It's pretty easy to find USBSerial interfaces that include a unique ID of some sort. That plus 4 seconds editing your udev config will give you stable device naming.

Re:rtty, old school technology (1)

bobbied (2522392) | about a year ago | (#45361849)

As I understood this suggestion, one was to go pickup a pile of identical USB to serial converters and USB hubs and just wire them all up. There will be nothing unique between the devices except how they are connected to the host USB hub and in which order the devices are initialized.

Re:rtty, old school technology (1)

Above (100351) | about a year ago | (#45360827)

I've not seen a hardware/software combination in the past ~5 years that varied the initialization order. Now, the order in which the USB ports are initialized is often non-intuitive and non-documented, but just plug a flash drive into each available port and reboot the server to find the order they are initialized in.

Where I see most people go wrong is they don't figure out the order the ports are initialized, and thus don't plug the serial device into the first to be initialized. By plugging into some other port, then adding a device and rebooting they get reordered.

Does it take some care? Yes. However it's also an order of magnitude cheaper than most of the packaged solutions, and leaves you with standard unix TTY's which open up a world of scripting opportunities.

Re:rtty, old school technology (1)

bobbied (2522392) | about a year ago | (#45361769)

Which makes my point. I'm not saying that the order is not set, but that anytime you make a change to the hardware configuration by plugging something in or removing a device you may unknowingly move a whole bunch of stuff in a way you don't understand. This might force you to have to go back though 120+ devices per host port and sort out what port is which device, just because something changed.

Consider what happens if one of your first 50 devices fails (say it comes unplugged or the cable breaks). What a MESS it's going to be sorting all that out.

No, I would not recommend this solution for any kind of "production" environment. Go get some serial port servers and do this right. Your life will be easier and the amount of time you save over the life of the system will more than pay for the hardware.

Re:rtty, old school technology (1)

Above (100351) | about a year ago | (#45364507)

I think you misunderstood what I said.

The OS (at least, Linux and FreeBSD) enumerate the motherboard ports in order. So if your motherboard has 8 ports you can discover the order and number them 1-8.

If you plug in a device to port 1, and then later plug the next device into port 2, there is no chance the first device will be renumbered.

However, if you plug into port 2, and later add a device on port 1, it will get renumbered.

So when I get a new motherboard, I take a pile of old 16M (yes, Meg) flash drives I have, and name them A-G or whatever, then plug them into every port and reboot the box. By checking which one is on which device, I can label the USB ports 1-N. All that has to be done then is always plug the new device into the next lowest port and there is no renumbering ever.

Yes, if one comes unplugged AND you reboot, the ones past it will renumber. However, plug it back in and reboot and it all numbers back just fine, no config work necessary.

I've deployed a few hundred of these, and maybe once every 2 years or so have a minor issue where a colo tech moves cables wrong. It's never taken more than 5 minutes and a reboot to fix though. I can also deploy 96 ports of serial for less than $2k, I don't know any other commercial solution that can come close to that price point.

Re:rtty, old school technology (0)

Anonymous Coward | about a year ago | (#45366619)

+1 Lucid

Re:rtty, old school technology (1)

drinkypoo (153816) | about a year ago | (#45362201)

Problem with this is that every time you plug in a new USB device, you are likely to totally hose the device names on the next reboot.

Look at /dev/bus/usb. Unless you lose a USB controller those device names should be stable.

Re:rtty, old school technology (0)

Anonymous Coward | about a year ago | (#45363285)

I recommend these, or some variation of them That way the serial devices become a telnet address.. and you don't tie the port to a particular computer..

Re:rtty, old school technology (0)

Anonymous Coward | about a year ago | (#45363413)

I recommend these, or some variation of them That way the serial devices become a telnet address.. and you don't tie the port to a particular computer..

The link should have been:
Moxa Serial to Ethernet [neteon.net]

Establish priorities first! (1)

mcrbids (148650) | about a year ago | (#45359155)

The most important thing is that it works reasonably well and doesn't require excessive administrative overhead. You've described a reasonably well managed configuration, so it's tough to justify changing everything "just because".

Exactly what would you accomplish by switching to an "open" technology? Answer that, and then you can make the best decision.

HP and Dell have "free" tools (1)

alen (225700) | about a year ago | (#45359387)

to manage their servers including console access via a special NIC port and the ability to push the power button remotely through a web browser

basic features are free. remote console is a $400 per server option called iLO Advanced on HP servers. the management software is free as well with some features licensed per server

Re:HP and Dell have "free" tools (1)

drinkypoo (153816) | about a year ago | (#45362215)

Beware the evils of OOB management. Much of the time, that functionality in a PC server is handled by an IPMI module, which is a little computer in its own right which will probably never receive adequate security patches and which has access to twiddle important configuration values in your system. They're wicked cool when they're not being used to own your network, though.

This is what I'm hearing (1)

viperidaenz (2515578) | about a year ago | (#45359415)

"We have something that works and I want to break it"

Re:This is what I'm hearing (1)

bobbied (2522392) | about a year ago | (#45360633)

I hear "I'm bored and I need something frustrating to do with my time."

Create your own community (1)

assantisz (881107) | about a year ago | (#45359435)

Open the source of your tools and make them available to the public. You will be able to grow your own community. I would LOVE to have a look at your home-grown stuff. We are an Avocent shop here when it comes to remote console/KVM/power access and so far the only tool we are currently looking into is DSView which a) is sucky enterprise-y software, b) extremely pricey, and c) does way more than we need it to do. Thanks to your posting, though, I found interesting links to tools like conman and powerman in the comments.

Livingston PortMasters (or similar) (1)

jlockard (140979) | about a year ago | (#45359455)

At $WORK we have used Livingston PortMasters to deal with our serial console issues. Network connected and logins can be setup to only have access to certain ports. Have worked well for us. Usually found pretty cheap on eBay.

Re:Livingston PortMasters (or similar) (1)

Nonesuch (90847) | about a year ago | (#45364039)

We did the same, but isolated all portmasters on a standalone switch, as the product line has been dead for years and the security in the product was pretty minimal even when Livingston and then Lucent was actually supporting the Portmaster. I think this guy is more asking about the software to handle the connections/auth/logging/etc rather than asking about a hardware solution?

Re:Livingston PortMasters (or similar) (1)

jlockard (140979) | about a year ago | (#45368117)

Actual implementation for us is also SSH'ing to a *NIX box, then tipping over to the PortMaster.

MRV (1)

spiffmastercow (1001386) | about a year ago | (#45359561)

Not sure if this is what you mean, but we use an MRV server that has a bunch of serial ports and provides an SSH port corresponding to each serial port.

Please help me understand (0)

Anonymous Coward | about a year ago | (#45359761)

Can someone help me understand why you need to manage servers over serial connections?

I can see how serial management of routers and stuff would be necessary, but why servers. I feel dumb for having to ask, so thanks in advance!

Re:Please help me understand (3, Insightful)

Bill_the_Engineer (772575) | about a year ago | (#45359849)

Serial consoles allows you to fix boot issues remotely.

Re:Please help me understand (0)

Anonymous Coward | about a year ago | (#45360665)

Yea, but only if you know how to use the command line. Otherwise, you are going to need that IP KVM....

Re:Please help me understand (0)

Anonymous Coward | about a year ago | (#45361687)

If you don't know how to use the command line then you most definitely shouldn't be the one administering these machines or any server.

Re:Please help me understand (1)

rubycodez (864176) | about a year ago | (#45361797)

Outside the realm of windows, for boot and boot issues you'll be in command line land anyway. Most mainframe and supercomputer and midrange and micros in my 30+ years of professional life other than windows, OS/2, later novell netware...all needed the command line skills.

this helped our company (0)

Anonymous Coward | about a year ago | (#45359785)

Our company got excellent results by using http://www.skyline.be/Products/AboutDataMiner.htm . Company has always been extremely friendly implementing "drivers" to take care of vendor specifics.

If it is not broke.. (1)

Bill_the_Engineer (772575) | about a year ago | (#45359823)

If the current system works well then don't try to fix it. " I'd rather use some tools with more of a community than just the 4 of us." is a very bad reason to try to install and learn a completely different system.

Unless more information is presented, I'll place this in the "idle hands are the devil's playground" category.

Re:If it is not broke.. (1)

LesFerg (452838) | about a year ago | (#45361553)

Well one aspect to consider is, keeping a bunch of staff tied into using some proprietary internally developed tools could also be isolating those staff from gaining any experience with current tools out there in the market and in use by many/most future employers. I am stuck in a situation like this myself, where any chance to get a new job will rely on me learning new development tools in my own time on my home PC, then trying to convince somebody that this is the same as workplace experience with the tools.

Out of consideration of your staff and their career development, they should be able to at least keep up with knowledge and preferably hands on experience of real world tools. Of course, some employers don't give a toss about such things.

Re:If it is not broke.. (1)

Bill_the_Engineer (772575) | about a year ago | (#45367209)

So you are suggesting that the employer should risk messing up a working system so that the current employees could develop a skill they could use at a new employer?

Consoleworks? (0)

Anonymous Coward | about a year ago | (#45360079)

Consoleworks is designed to connect and manage multiple serial consoles, and provides logging, alerts, etc.

http://www.tditechnologies.com/

(full disclosure: I'm one of the patent inventors, but have no current financial interest)

Re:Consoleworks? (1)

leadfoot (159248) | about a year ago | (#45368023)

Consoleworks is what we used at one of my previous employers. It had software that would run on Windows or Linux.

It'all there! Why don't you use it? (0)

DF5JT (589002) | about a year ago | (#45361055)

Disclaimer: I work for these guys: http://www.ovirt.org/Features/DRBD [ovirt.org]

As somebody said before, this shop sounds like a fragile thing if some of those people leave. If customers depend on it, it might be advisable to switch to standardized tools for managing KVM environments. oVirt is the upstream project to Red Hat Enterprise Virtualization, i.e. those guys who really know KVM.

http://www.ovirt.org/OVirt_3.0_Feature_Guide [ovirt.org]

oVirt has pretty much everything he could ever dream of - and it is well documented, so any successor will immediately be able to handle the environment. Of course Open Source, it has a very active community with real experts:

http://www.ovirt.org/Documentation [ovirt.org]

Can't think of any reason no to use oVirt. It the exact feature set the OP is looking for, addressing his specific needs:

"Having a minimal CLI console available can make the product more attractive to users who use the command line and prefer to avoid using the GUI. It can also provide a simple and fast shell that requires no special client besides an ssh client, without having to connect to the actual VM. Serial console access can also be used for VM troubleshooting at the lower level."

Here you are:
http://www.ovirt.org/Features/Serial_Console_in_CLI [ovirt.org]

Also, oVirt has a very active community:
http://lists.ovirt.org/pipermail/users/ [ovirt.org]

Take a look, it's free...

Simple solution (0)

Anonymous Coward | about a year ago | (#45361573)

Since you haven't specified what the problem is, I'm guessing you're hung up on how to "mux a bunch of muxes." The key is to write two simple scripts: one to lookup which mux a given server lives on, and another to dispatch the mux command to the correct mux. Here's the latter:

#!/bin/bash
SERVER=$1
MUX=$(lookup-server-mux.sh $SERVER)
/usr/bin/ssh $MUX $*

Usage:
mux-muxer.sh HOST [COMMAND]

Now you just have to write lookup-server-mux.sh using your favorite database, and make sure all the server names are unique. Personally I'd use grep and sed on a plaintext file (literally just two piped commands), but you might prefer to use NOSQL or something else entirely (regardless of language, try to stay under 20 lines, or you're provably over-engineering it).

You're welcome.

p.s. I don't actually advocate using two 3-4 line scripts in production. You should add some error checking and syntax help if more than four of you will be using it.

What's wrong with ILO? (1)

snowsnoot (3389789) | about a year ago | (#45364095)

Im a little lost.. why not using ILO/ILOM/DRAC etc.. its all the same thing. Just give each ILO IP a DNS address and ssh to it, log in and there you have all the tools you need, a way to access the system console, power on/off remotely, check hardware events, hell it can even send SNMP traps to a NMS so you get alerts even if the OS dies! Using serial is so old hat, and clunky. Why on earth would anyone be using it at all these days? Serial! LMAO *scoffs*

Re:What's wrong with ILO? (1)

Simon Rowe (1206316) | about a year ago | (#45365755)

How long have you got? ILO often hangs (as in the ILO *server*) when extremely long lines are sent to it. Some features as licensed on per-host basis. Unless you only have one supplier you end up with having to use a mixture of tools to do the same operations. I haven't used one of these proprietary tools that doesn't suck big-time. The worst offender is Dell's Java KVM. I have to fire up a Windows VM whenever I have to use it. Once configured serial just works.

If it is not broken... (1)

manu0601 (2221348) | about a year ago | (#45364469)

If it is not broken, do not fix it. Your installation seems to work, why do you want to waste time "fixing" it?

I use serial comms at work frequently... (1)

Endloser (1170279) | about a year ago | (#45364711)

and I tend to use /usr/bin/minicom.
Some of the guys at work prefer /usr/bin/screen.

Both have huge followings and have been around a long time.
Screen sounds like it may do what you want easiest.

But neither of these are going to work for the power management aspect.
I think you may find you will need to use your custom scripts for that with most solutions.

Go Old school - Conserver (0)

Anonymous Coward | about a year ago | (#45367769)

http://www.conserver.com/consoles/

Conserver is an application that allows multiple users to watch a serial console at the same time. It can log the data, allows users to take write-access of a console (one at a time), and has a variety of bells and whistles to accentuate that basic functionality. The idea is that conserver will log all your serial traffic so you can go back and review why something crashed, look at changes (if done on the console), or tie the console logs into a monitoring system (just watch the logfiles it creates). With multi-user capabilities you can work on equipment with others, mentor, train, etc. It also does all that client-server stuff so that, assuming you have a network connection, you can interact with any of the equipment from home or wherever.

Cereal (1)

Delusionner (558717) | about a year ago | (#45369103)

Hey there, We are in the process of migrating away from proprietary serial console servers to one that's based on simple hardware and open source software. See http://cmrg.fifthhorseman.net/wiki/cereal [fifthhorseman.net] it's also packaged in debian already.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?