> Is this a feature that is supported currently or am I stretching it? Other > than that I can connect and interact with console from the local server.

well, it's supported in that as long as you chat using the protocol it's expecting, yes.

oh, and going directly to the higher-numbered port instead of the -p arg and then using the protocol to find the console may not always work...it probably will, depending on what the machine is doing, but it's not guaranteed (and if you edit the config and send a HUP, all bets are off).

i'd certainly like to know why you're trying to avoid the client, 'cause if something is lacking, it might be possible to add an enhancement. but i can imagine edge cases that would require it...

Thanks for the reply. I am trying to emulate a Cisco 2511 or equivalent. Searching through the mailing-lists I found ser2net and it is working like I need for my situation.

On 3/30/06, Bryan Stansell <bryan [at] conserver> wrote: > > On Thu, Mar 30, 2006 at 08:44:08PM -0500, Ryan DeBerry wrote: > > I want to be able to telnet to the conserver and use it in that aspect. > > why? the console client can run just about anywhere. > > > I can telnet to port 50000 and connect to a console, however there is no > > interaction after you connect a console. > > see https://www.conserver.com/pipermail/users/2006-March/msg00033.html,> sounds like the same issue. > > > Is this a feature that is supported currently or am I stretching > it? Other > > than that I can connect and interact with console from the local server. > > well, it's supported in that as long as you chat using the protocol it's > expecting, yes. > > oh, and going directly to the higher-numbered port instead of the -p arg > and then using the protocol to find the console may not always work...it > probably will, depending on what the machine is doing, but it's not > guaranteed (and if you edit the config and send a HUP, all bets are > off). > > i'd certainly like to know why you're trying to avoid the client, 'cause > if something is lacking, it might be possible to add an enhancement. > but i can imagine edge cases that would require it... > > good luck! > > Bryan > _______________________________________________ > users mailing list > users [at] conserver > https://www.conserver.com/mailman/listinfo/users>

On Thu, 2006-03-30 at 21:17 -0500, Ryan DeBerry wrote: > Thanks for the reply. I am trying to emulate a Cisco 2511 or > equivalent. Searching through the mailing-lists I found ser2net and > it is working like I need for my situation. >

Well you've created a dumb terminal server with none of the features of conserver. If you want one of those look on eBay for old Computone RAS2000s

Bryan Stansell wrote: > i'd certainly like to know why you're trying to avoid the client, 'cause > if something is lacking, it might be possible to add an enhancement. > but i can imagine edge cases that would require it...

In my case, I was avoiding the client because of support issues: most of the organization at my location uses Windows, and although a number of users have Cygwin, most of them didn't install the compilers and libraries necessary to build the client. It also turns out that distributing a Cygwin binary from my box requires a very similar Cygwin install on other people's machines. Or something. It's complicated.

A standalone, Win32-native (non-cygwin) build of console would be lovely, if someone could instruct me in doing it.

Meanwhile, the *bigger* issue is time and education. Nearly everybody uses Terra Term (ugh!) connected to their own box, and the only advantage most people see in conserver is the ability to centralize the logging of all the QA terminals to our fileserver, and adding timestamps every minute.

I'm wearing my QA hat at this job, not the sysadmin hat. It's been easier for me to sell the idea of installing Ruby and using automation scripts I've written, rather than having people build stuff on cygwin. That said, nobody but me has bothered using this anyway, even though I've written internal documentation. I get the feeling that this is an uphill and mostly pointless battle now.

On Fri, 2006-03-31 at 08:30 -0700, Chris Riddoch wrote: > In my case, I was avoiding the client because of support issues: most > of > the organization at my location uses Windows, and although a number of > users have Cygwin, most of them didn't install the compilers and > libraries necessary to build the client. It also turns out that > distributing a Cygwin binary from my box requires a very similar > Cygwin > install on other people's machines. Or something. It's complicated.

Well there is no Win32 code in console so it is not native. You need Cygwin. a few years back I compiled a version in Cygwin and made it available to our customers. You do not need the Cygwin environment. You only need the dll. So I created a zip file that contained console.exe and cygwin?.dll. It worked fine on the cmd.com prompt.

On Fri, Mar 31, 2006 at 10:49:02AM -0500, Christopher Fowler wrote: > available to our customers. You do not need the Cygwin environment. > You only need the dll. So I created a zip file that contained > console.exe and cygwin?.dll. It worked fine on the cmd.com prompt.

and this should work with 8.x.x as well. you might need to compile things with '--with-port=XXX' so that an /etc/services lookup isn't needed, but aside from that, i don't see why dropping console.exe and cygwin1.dll in a directory and running it won't work. haven't tried, however (i have a small development cygwin environment on my laptop).

the exception to this might be if you compile with ssl or other extra libraries...the might require extra things to distribute.

as for the education issue, well, perhaps it's just not right for your environment. i would make the claim that conserver would be right for *any* environment since it allows for logging (so you can go back and see what was wrong) and cooperative work on a single console. just those two features alone (not to mention the many others) make it worth the effort in my book. but, work habits and a willingness for change can be a long, hard battle, so you should obviously do what you feel is right.

sure would be entertaining to at least have a native console binary for windows...that would help ease everyone's pain. who knows how tricky that'll be, though (i'm no windows programmer, that's for sure).

On Fri, 2006-03-31 at 08:05 -0800, Bryan Stansell wrote: > and this should work with 8.x.x as well. you might need to compile > things with '--with-port=XXX' so that an /etc/services lookup isn't > needed, but aside from that, i don't see why dropping console.exe and > cygwin1.dll in a directory and running it won't work. haven't tried, > however (i have a small development cygwin environment on my laptop).

I do remember having to use --with-port=XXX option. I also remember having to compile as static. I was hoping static would remove the cygwin1.dll requirement but that was the only one required.

Bryan Stansell wrote: > On Fri, Mar 31, 2006 at 10:49:02AM -0500, Christopher Fowler wrote: >> available to our customers. You do not need the Cygwin environment. >> You only need the dll. So I created a zip file that contained >> console.exe and cygwin?.dll. It worked fine on the cmd.com prompt. > > and this should work with 8.x.x as well. you might need to compile > things with '--with-port=XXX' so that an /etc/services lookup isn't > needed, but aside from that, i don't see why dropping console.exe and > cygwin1.dll in a directory and running it won't work. haven't tried, > however (i have a small development cygwin environment on my laptop).

I'll give that a try when I get a chance. I hadn't thought to build a static binary (another suggestion I got).

> sure would be entertaining to at least have a native console binary for > windows...that would help ease everyone's pain. who knows how tricky > that'll be, though (i'm no windows programmer, that's for sure).

One idea is having them ssh or telnet to the console server, logging ing and then executing console directly. With a front end on the console server you can make this easy on them

On Fri, 2006-03-31 at 09:13 -0700, Chris Riddoch wrote: > Bryan Stansell wrote: > > On Fri, Mar 31, 2006 at 10:49:02AM -0500, Christopher Fowler wrote: > >> available to our customers. You do not need the Cygwin environment. > >> You only need the dll. So I created a zip file that contained > >> console.exe and cygwin?.dll. It worked fine on the cmd.com prompt. > > > > and this should work with 8.x.x as well. you might need to compile > > things with '--with-port=XXX' so that an /etc/services lookup isn't > > needed, but aside from that, i don't see why dropping console.exe and > > cygwin1.dll in a directory and running it won't work. haven't tried, > > however (i have a small development cygwin environment on my laptop). > > I'll give that a try when I get a chance. I hadn't thought to build a > static binary (another suggestion I got). > > > sure would be entertaining to at least have a native console binary for > > windows...that would help ease everyone's pain. who knows how tricky > > that'll be, though (i'm no windows programmer, that's for sure). > > Yeah, neither am I. I'm trying to stay sane with SuSE on VMWare. (sigh) >