SEO

I'd like to log into a box remotely and run a curses-based program, but
have the output display on the console for a colleague to view. Is this
possible?

If so, can it be sent to the console screen without anyone being logged in?

For example, I'd like to launch top, have it appear on the screen, and
continually update normally, without scrolling.

> I'd like to log into a box remotely and run a curses-based program, but
> have the output display on the console for a colleague to view. Is this
> possible?

*I might be very wrong here*
But my though is that unless you make use of the X server
for exporting Xterm consoles your stuck with screen as
far as the managing go's on terminals (Do note the *)

I'm running multiple serial console related tools in the background
for multiple users using screen,

Have a try
# ftp "ftp://ftp.openbsd.org/pub/OpenBSD/`uname -r`/\
packages/`uname -m`/screen*static.tgz"
# pkg_add -v screen-*

---user a
$ screen top
press [ctrl] + [a] + [d]
[session detached]
---user b
$ screen -r

> If so, can it be sent to the console screen without anyone being logged
> in?

Try looking at the screen man page, it has loads of options.
It might have some sort of /etc/ttys redirect, mix that with ssh
and your problem should be solved.

> For example, I'd like to launch top, have it appear on the screen, and
> continually update normally, without scrolling.

If all fails dump top output to a file.

$ while true;do top -b -o cpu && sleep 1 && clear;done >> /tmp/output

Hope this helps.


--
] Bas Keur
] `Energizer Bunny arrested, charged with battery`

"Bas Keur" <bas.keur@dmrt.net> wrote in
news:42044e31$0$28980$e4fe514c@news.xs4all.nl:

>> I'd like to log into a box remotely and run a curses-based program,
>> but have the output display on the console for a colleague to view.
>> Is this possible?
>
> *I might be very wrong here*
> But my though is that unless you make use of the X server
> for exporting Xterm consoles your stuck with screen as
> far as the managing go's on terminals (Do note the *)
>
> I'm running multiple serial console related tools in the background
> for multiple users using screen,
>
> Have a try
> # ftp "ftp://ftp.openbsd.org/pub/OpenBSD/`uname -r`/\
> packages/`uname -m`/screen*static.tgz"
> # pkg_add -v screen-*

And who says OpenBSD needs apt-get? Seriously, thanks, I was just trying
to figure out a way to simplify fetching packages from my favorite
mirror. I can use this to create a function in my profile.

> ---user a
> $ screen top
> press [ctrl] + [a] + [d]
> [session detached]
> ---user b
> $ screen -r

Nice tip. I use screen a lot, but it won't work for me in this instance.
It needs to be a passive experience for user b, who has very fat fingers.
Imagine user b is watching TV, but I have the remote.

>> If so, can it be sent to the console screen without anyone being
>> logged in?
>
> Try looking at the screen man page, it has loads of options.
> It might have some sort of /etc/ttys redirect, mix that with ssh
> and your problem should be solved.
>
>> For example, I'd like to launch top, have it appear on the screen,
>> and continually update normally, without scrolling.
>
> If all fails dump top output to a file.
>
> $ while true;do top -b -o cpu && sleep 1 && clear;done >> /tmp/output

The simplest solution seems to be this:

top > /dev/console

This does exactly want I want it to do.

But it requires someone to be logged in at the console.

So I created a user with a restricted shell. :P

While it's possible to direct output to the console when nobody is logged
in, it's sometimes unreadable. For example, ntop works great (as long as
nobody touches the keyboard), but top doesn't.

> Hope this helps.

It did. Thanks. screen will come in handy when I want to output something
to the console but leave it running for a while. I can simply detach from
the session and attach to it later.

> And who says OpenBSD needs apt-get?

A little voice in my head says it misses `the upgrade` function
from rpm/apt etc. Then again, we all know what kind of
problems THAT will/can/shall cause

> Seriously, thanks, I was just trying
> to figure out a way to simplify fetching packages from my favorite
> mirror. I can use this to create a function in my profile.

Well, in this case you might even like my 'Lazy Bum' script
http://www.dmrt.net/viper/code/scrip...age_install.sh
1: Like you said, plz use a local mirror in it.
2: Have ncftp installed to use it.

[viper@aspav viper]$ sh package_install.sh
[viper@aspav viper]$ grep wget package_install.html
pkg_add -v ftp://ftp.nluug.nl/pub/OpenBSD/3.6/p...wget-1.8.2.tgz

I gave up on Windows servers a long time ago,
but i kept the mouse as well as the copy/paste habbit =]

>> $ screen -r
>
> Nice tip. I use screen a lot, but it won't work for me in this instance.
> It needs to be a passive experience for user b, who has very fat fingers.
> Imagine user b is watching TV, but I have the remote.

(How cruel
May the user `interact` with the tool ?
Or is it some sort of monitor/stats idea ?
Is there any reason why an X server doesn't do the job ?
Just give him a windows box and install something like
exceed or reflection (Win32 X servers) so you can
export a display/terminal running the req. program to his
windows machine. You can specify some nice policies as
well, so he can't ctrl+z a shell etc. (A friendly warning while
holding a lead pipe works pretty fine as well.)

> top > /dev/console
> This does exactly want I want it to do.
> But it requires someone to be logged in at the console.

Not when running it with screen noh ?

> So I created a user with a restricted shell. :P

Wich one, just curious.

> While it's possible to direct output to the console when nobody is logged
> in, it's sometimes unreadable. For example, ntop works great (as long as
> nobody touches the keyboard), but top doesn't.

Hmmm, i'm pretty sure ntop comes ncurses.
curses(3) - CRT screen handling and optimization package
This is the reason why i guess.

Try some different terminals

# grep console /etc/ttys
console "/usr/libexec/getty Pc" vt220 off secure

Maybe you can replace the vt220 term with ansi or xterm-color
*never tried it though*

>> Hope this helps.
>
> It did. Thanks. screen will come in handy when I want to output something
> to the console but leave it running for a while. I can simply detach from
> the session and attach to it later.

Handy with torrent clients & irc as well


] Bas Keur
] `Energizer Bunny arrested, charged with battery`

"Bas Keur" <bas.keur@dmrt.net> wrote in
news:420556c1$0$28975$e4fe514c@news.xs4all.nl:

>> And who says OpenBSD needs apt-get?
>
> A little voice in my head says it misses `the upgrade` function
> from rpm/apt etc. Then again, we all know what kind of
> problems THAT will/can/shall cause
>
>> Seriously, thanks, I was just trying
>> to figure out a way to simplify fetching packages from my favorite
>> mirror. I can use this to create a function in my profile.
>
> Well, in this case you might even like my 'Lazy Bum' script
> http://www.dmrt.net/viper/code/scrip...age_install.sh
> 1: Like you said, plz use a local mirror in it.
> 2: Have ncftp installed to use it.
>
> [viper@aspav viper]$ sh package_install.sh
> [viper@aspav viper]$ grep wget package_install.html
> pkg_add -v
> ftp://ftp.nluug.nl/pub/OpenBSD/3.6/p...wget-1.8.2.tgz

Thanks, that's handy. Do you have one that will apply security updates
(now, who's the lazy bum)?

But seriously, what is the best way to update OpenBSD? And to keep it
interesting, what is the best way to do it on a 486 with 16MB of RAM and
138MB of free disk space? ))

> I gave up on Windows servers a long time ago,
> but i kept the mouse as well as the copy/paste habbit =]

Huh. You can use Windows on servers? That would make an interesting
experiment...

> >> $ screen -r
>>
>> Nice tip. I use screen a lot, but it won't work for me in this
>> instance. It needs to be a passive experience for user b, who has
>> very fat fingers. Imagine user b is watching TV, but I have the
>> remote.
>
> (How cruel

Only to be kind...

> May the user `interact` with the tool ?

No.

> Or is it some sort of monitor/stats idea ?

Yes.

> Is there any reason why an X server doesn't do the job ?

Disaster is only a mouse click away.

> Just give him a windows box and install something like
> exceed or reflection (Win32 X servers) so you can
> export a display/terminal running the req. program to his
> windows machine. You can specify some nice policies as
> well, so he can't ctrl+z a shell etc. (A friendly warning while
> holding a lead pipe works pretty fine as well.)

I'm already using Cygwin with excellent results, and have considered
setting it up on user b's computer to do as you propose. In fact, the use
of special purpose ssh keys may make this a plausible way for user b to
start the programs without my intervention.

>> top > /dev/console
>> This does exactly want I want it to do.
>> But it requires someone to be logged in at the console.
>
> Not when running it with screen noh ?

I can start it from a screen session and detach, if that's what you mean.
As for handing the screen session over to someone else, it might be like
handing the steering wheel over to an inexperienced driver. Lesson 1:
"UNIX is case-sensitive." Lesson 2: "There is no C: drive." You get the
idea...

>> So I created a user with a restricted shell. :P
>
> Wich one, just curious.

It works with rksh, which comes with the basic installation of OpenBSD.
But since I prefer bash, and already tailored /etc/profile for it, I
created a symlink to it named rbash, which serves the same purpose.

>> While it's possible to direct output to the console when nobody is
>> logged in, it's sometimes unreadable. For example, ntop works great
>> (as long as nobody touches the keyboard), but top doesn't.
>
> Hmmm, i'm pretty sure ntop comes ncurses.
> curses(3) - CRT screen handling and optimization package
> This is the reason why i guess.
>
> Try some different terminals
>
> # grep console /etc/ttys
> console "/usr/libexec/getty Pc" vt220 off secure
>
> Maybe you can replace the vt220 term with ansi or xterm-color
> *never tried it though*

No effect.

But ntop is really the application I had in mind, so I'm pretty happy,
for now.

Thanks for your help.

> Thanks, that's handy. Do you have one that will apply security updates
> (now, who's the lazy bum)?

lynx -dump www.openbsd.org/errata.html|grep pub|awk '{print $2}'
Or have a daily visit at www.undeadly.org

> But seriously, what is the best way to update OpenBSD?

For as far as patching go's
cd /usr/src
patch -p0 < 001.file.patch

I try to avoid having to upgrade the OS by from /usr/src.
It's not that i expect any problems, it's just that a new install
takes about 10 minutes & i'm sure the box is `fresh`

> And to keep it interesting, what is the best way to do it on
> a 486 with 16MB of RAM and 138MB of free disk space? ))

Are you working in a museum ? A 486 whould take about
<guessing> 4 days to recomile /usr/src. May i suggest you
trow it from a bridge

>> I gave up on Windows servers a long time ago,
>> but i kept the mouse as well as the copy/paste habbit =]
> Huh. You can use Windows on servers?
> That would make an interesting experiment...

A mental one.

>> Or is it some sort of monitor/stats idea ?
> Yes.
>
>> Is there any reason why an X server doesn't do the job ?
> Disaster is only a mouse click away.

Then.... unplug it

>> Just give him a windows box and install something like
>> exceed or reflection (Win32 X servers) so you can
>> export a display/terminal running the req. program to his
>> windows machine. You can specify some nice policies as
>> well, so he can't ctrl+z a shell etc. (A friendly warning while
>> holding a lead pipe works pretty fine as well.)
>
> I'm already using Cygwin with excellent results, and have considered
> setting it up on user b's computer to do as you propose. In fact, the use
> of special purpose ssh keys may make this a plausible way for user b to
> start the programs without my intervention.

ok

> I can start it from a screen session and detach, if that's what you mean.
> As for handing the screen session over to someone else, it might be like
> handing the steering wheel over to an inexperienced driver. Lesson 1:
> "UNIX is case-sensitive." Lesson 2: "There is no C: drive." You get the
> idea...

Thats why i like the reflection/exceed packages, it's very idiot proof.
He just have to `click` the icon, wich will rsh/ssh/telnet whatever
to wherever and run some giving shell commands. The only thing
the user is getting on his screen is the ending result.

>>> So I created a user with a restricted shell. :P
>> Wich one, just curious.
>
> It works with rksh, which comes with the basic installation of OpenBSD.
> But since I prefer bash, and already tailored /etc/profile for it, I
> created a symlink to it named rbash, which serves the same purpose.

Ok, you might also want to compile your own bash from source
and run the bofh patch over it. Logs keystrokes trough syslog
http://www.ccitt5.net/archives/bash-...b-0.0.1.tar.gz
For the real paranoid

>>> While it's possible to direct output to the console when nobody is
>>> logged in, it's sometimes unreadable. For example, ntop works great
>>> (as long as nobody touches the keyboard), but top doesn't.
>
>> Maybe you can replace the vt220 term with ansi or xterm-color
>> *never tried it though*
>
> Thanks for your help.

ok


--
] Bas Keur
] `Energizer Bunny arrested, charged with battery`

"Bas Keur" <bas.keur@dmrt.net> wrote in
news:4205b458$0$28986$e4fe514c@news.xs4all.nl:

>> Thanks, that's handy. Do you have one that will apply security
>> updates (now, who's the lazy bum)?
>
> lynx -dump www.openbsd.org/errata.html|grep pub|awk '{print $2}'
> Or have a daily visit at www.undeadly.org
>
>> But seriously, what is the best way to update OpenBSD?
>
> For as far as patching go's
> cd /usr/src
> patch -p0 < 001.file.patch
>
> I try to avoid having to upgrade the OS by from /usr/src.
> It's not that i expect any problems, it's just that a new install
> takes about 10 minutes & i'm sure the box is `fresh`

Same here, I'm just interested in security updates for the latest stable
release, and the only information I've seen involves patching source. I
was hoping that there were replacement packages that could be installed
over the old ones. I see the ones at:

http://www.openbsd.org/pkg-stable.html

but they don't include things from the errata page (no BIND, for
example).

>> And to keep it interesting, what is the best way to do it on
>> a 486 with 16MB of RAM and 138MB of free disk space? ))
>
> Are you working in a museum ? A 486 whould take about
> <guessing> 4 days to recomile /usr/src. May i suggest you
> trow it from a bridge

Someone already did. Guess who found it? On a lark, I installed OpenBSD
on it and am currently using it as the DNS server on my home network.
Noone is more surprised than I am that this box could be recycled.
Because OpenBSD can be installed on boxes with such tight disk
constraints (this one is 290MB), it's a good candidate for installing on
a Compact Flash card using an IDE adapter on a mini-ITX. This is one
reason I am interested in binary security updates (a distant second to
pure laziness).

My other boxes can patch the source without any difficulty. But those
will also be slow and underpowered one day. Running stress tests on my
50MHz 486 can give me a glimpse into The Future. In fact, apache is
delivering a blazingly fast 10 requests/sec on it as we speak (Uh-oh,
just took it offline with 100 concurrent requests. "Fast and capable
486DX2", my ass.).