Conference csc32::consolemanager

We've checked the terminal server port and cabling and PCM server config 
by replacing the machine with a working on in the port that was being used 
by this faulty-machine. We used the same cable and a different one, 
the port, and used PCM and telnet to connect and lo and behold 
everything works fine. 

This means the only thing left with a possible problem is 
the setup on the machine we can't reach. 

Which was ok until 4am yesterday morning just after NSR 
finished it's backups. 



Whilst I attempt to get some documentation - 
currently I have this conference and that's about it. 

The bookreader docs require a licence I've not got yet (and 
doubt I'll be able to install if it really is VAXCLUSTER-CONSOLE,
and I appear to be having a major syntax/permission/network 
problem with getting copies of the ones on OPG::




sigh


 

Ok! Progress! (well, I'm happy I've made some even if it 
isn't that much).

I've now got sets of the documents from OPG. 
I've now skimmed them. 
I've now established that by everything in these the 
setup is alright so far. 

All that I'm missing now (other than a shotgun to the head
from one of our banking customers - which I will have Monday 
morning if I can't come up with some better suggestions than 
the few remaining checks I have) is quite what the setup on 
the system being serviced is meant to be, if there are limitations
etc etc. 

Everything is ok ....in PCM....down the telnet connection to the
terminal server......out it's ports....and even down the cable. 

It's been tested with another machine on the end. 

Our remaining possible sites of the problem as far as 
I can tell are: 

* h/w of the port on the 3000/400 it connects to 

* the device file for that 

* an element of this whole equation I'm not aware of 
          even though I've tried to find out all I can. 


Incidentally I probably won't be asking this level of 
"I don't know what I'm doing that well" questions for 
long if its any consolation - I should have the workstation
I'm writing this note on managing a Decserver3100 (well how 
can it be a DECstation if it's donated it's graphics head to 
the Polybeast?)

..and one more incidentally if I don't get through to anyone 
in Dublin and there's someone reading here ...

Have we got 1.5a out to them yet?????? 

Although the release notes etc don't mention this I'm sure
it'll help!!


Any suggestions beyond my    file /dev/tty01, ls -aulg /dev/tty01
and seeing what /dev/console is ? 

(not that I know what this setup is meant to look like anyway -
just that it worked 'til 4am yesterday morning and I've got to 
fix it - I'm guessing /dev/console is a link to /dev/tty01)

If I'm really lucky I'll find /dev/tty01 is a stonking great 
text file full off all the console output for the last couple 
of days.... so not only can I just mknod /dev/tty01 c+b  24  3
and we'll be on line and working again but we'll have all the old 
console output saved in a file. 

Then again, if it is that the case it could be nasty because if it's 
at all busy this weekend the output to the console of 4 days of activity 
when it's got system watchdog running and outputing to the console 
and NSR doing the same each night on top of the usual output then 
we're going to have a very very full root file system on one of this 
banks main machines and we're also going to be unable to write to the 
console because of the file system being full so it should hang within 
a split second of the boot. 

In fact as I'm thinking this as I write it I'm not sure I can possibly 
leave this system without having checked this even if they do have 
tty01 as a text file...... (horrible train of thought this is!) 

Still all I can do is ring and see if they have anyone with the root 
password and an ability to listen to me and type what I say :-) 


regards

Jo.

    Jo
    
    ... amazing notes, truly amazing... and refreshing
    
    I've stayed out of this one because I am a VMS/LAT PCM user, which is
    just about as different as can be from you. However, there may be a
    couple of points that may help - let's hope!
    
    Firstly, (not real hopeful here, since the connection has worked on
    other (plural?) nodes) is to login to the terminal server and logout
    the port to which this recalcitrant is connected.
    
    Secondly, here I have to believe the model that you have suggested (it
    is very, very different from the VMS model) is that you stop any PCM
    software that may be running on this remote node and then restart it.
    If this sort of software doesn't exist, yet the tty configuration has
    been working and noone can say what's wrong, then is a reboot of the
    offender possible? The really nasty side effect here is that you might
    lose all that output.
    
    I don't like suggesting this sort of thing, but desperate times,
    desparate measures...    no, no, DON'T blow it up!
    
    Tony Sherrard
                                                                          

Tony,   

VMS and LAT or not I'm very thankful for your reply -
at least I know there's someone listening a bit. 

Also, with regard to the Unix/VMS setup being 
different on managED - don't take the impression I  may 
give for it!   The whole reason for this note is I have no idea
how the managed system is meant to be set up. 

What I understand from what the customer has described 
on managed machines is the total that I know - I spent a day 
learning about the product on some of Simon and Phils systems 
with a colleague - only now do I realise all of what we did was 
on the managing system - though I can see why - of all the 
docs I've pulled over the setup explainations seem to stop at 
the terminal server. 

Although I'm rapidly suspecting there is nothing more than 
a command or two of OSF/1 setup and no Polycenter stuff to 
install to this it is the first time I've come across this 
requirement of setup so am not certain waht exactly is needed 
and I also still have no idea whether my guesses are going in
the right direction as to how it should be sets up.

The information I have from the customer relating to the managed
machine is that this is a 3000/400 (it says 3000_500 in the config 
file but it's a lie downer not a standuper) and they're using the 
little telephone wire so it's the mmj port which is tty01 on those
to feed the console information to PCM. 

That it worked until 4am last Thursday morning when I spent 
the first half of the day on the call there was some confusion 
over what they wanted. 

>is to login to the terminal server and logout
>    the port to which this recalcitrant is connected.

The suggestion of a reboot of the terminal server will fix this 
won't it..  

I did a few checks this morning with the manager who was explaining to 
me last Friday how important this was to their set up and how they need 
it fixed asap.   I have to have some more to do for about 11 when the 
techie gets into work. (Lucky her! Home at 4:30 when I'm in 'til 8 and 
not in 'til 11 when I'm in at 9 - and rushing in at that cause her 
manager is hassling me!  But we shan't mention that one :-) 

ls -aulg /dev/console
crw--w--w-   1 root      terminal    0,  0 Jan 23 09:08 /dev/console

ls aulg /dev/tty01
crw rw rw    1 root     system  24,    3   0ct  19  12:20 /dev/tty01

ls -aulg /dev/tty00
crw-rw-rw-   1 root    system    24,  2   Jan 23 09:08 /dev/console


file /dev/console
character special (0/0) VS_SLU �0 terminal �3 modem_control off

file /dev/tty01
character special (24/3)

file /dev/tty00
character special (24/2) VS_SLU �0 terminal �2 modem_control off

Which sort of implies to me that something has been done to switch 
around the names of tty01 and console in that terminal 3 is normally 
tty01 not the console - however the major minor numbers are still 
on the right devices so I give in. 

If I knew what was meant to be here I could at least know if this 
wierd combination is valid or the obvious reason we're having a 
problem. 

I suspect it's incorrect, however that doesn't leave me with much 
to do since the answer to how to correct it is also the answer to 
how's it meant to be set up in the first place, to which the answer is 

"I don't know!"


inittab had 
cons:1234:respawn:/usr/sbin/getty console console vt100
as the only mention of console other than redirection of output to,
and no mention of tty01 or 00.

cat /etc/printcap > /dev/console or tty00 return the prompt ok, 

cat /etc/printcap > /dev/tty01    however returns:

/dev/tty01 no such device or address

Now this rings bells - unfortunately they sound like lat 
groups bells and I don't see how LAT groups can be working on 
a telnet connection, in fact even more so I'm not aware of what 
could have been done on the other machines telnet connection 
to make it the member of the right groups so it didn't fail. 


If nothing else as a standby I'll get Catriona to actually 
read out to me *every single thing show port on the terminal 
server outputs and double check every entry. Then log the 
port out if there's a connection and reboot the terminal 
server if we can. 




Again as before any suggestions more than welcome, 

what would however be most welcome of all would be if someone 
who knows how you are meant to set up the hosts being managed
or where there's documentation of what you do could please tell 
me, asap!


I'm starting to wonder whether we need someone on site but 
without the ability to know what's meant to be set up it's a 
bit hard to justify. 


Jo. 

    Jo
    
    If it's OSF stuff, I'm lost... sorry. Since the physical path from the
    managed system to PCM has been working I assume that all connections
    are still correct? Operators have been known to do strange things at
    04:00
    
    A logout of the port should not also require a terminal server reboot.
    After the logout leave it a while then check that a connection has been
    made to that port.
    
    Yes, it sounds as though you need some OSF help...
    
    Tony

A smaller question that might solve this if someone can answer it:

Is it possible to run console manager from a port on the 
workstation other than the console port(eg: tty01)?

It seems to me the documentation suggests one requirement 
of PCM receiving the data is that there must NOT be a 
getty running on the port in question so it can get 
access to the messages being re-routed to there. 

It would also seem from an OSF/1 viewpoint that simply 
telnetting to the port on the machine in question will 
not provide a login: prompt or access to the machine 
unless there IS a getty running. 

Therefore if you are not using /dev/console and 
wiring into the *real* console port where the 
monitor normally used as a console is kept then 
you can only use one or other facility from PCM at 
a time and inbetween changes you must add or remove
the relevant tty from inittab and init q to reread 
inittab before attempting the other action.

This is all also based on the assumption that 
/dev/console is a special device, more so than 
/dev/tty01, in that it will still allow messages
to me written to the device even when a getty has 
already been started against it. 


Effectively, if my understanding is correct, tty01
would have to be re-build/re-engineered/re-designed 
in order for PCM to be able to use it with the same 
ease that it uses /dev/console. 

jo. 

In case anyone wonders the answer - it would be possible
for the simple reason that a getty will take no notice of 
output to the device since it's waiting for input :-) 

Tried tested and catted all over the place on my 
workstation here with a getty running on it. 


Hence it would seem the major issue in the 
previous couple of notes might well be solved 
by starting a getty on tty01 and rebooting the machine
to flush any old setups, then making sure there is
output being sent to tty01 by syslog and the 
like in syslog.conf since it wasn't there before. 

Messy, inadvisable, might be a bit wobbly, and completely and utterly 
dependant on the scripts that take a copy of output from /dev/console 
and copy it to tty01 working and making sure no-one removes the getty 
from that line - but possible basically.... 


Jo.