OSR5: how to find out disabled terminals by authorization subsystem?

Hello.

I am giving a test drive to OSR5 (without graphical environment), so far
so good.

After manually defaulting to the Korn Shell, changing the "intr" code to
CTRL-C, going through the install with a broken "Spanish" keyboard map,
setting TIMEOUT=20 in /etc/default/boot so the machine starts directly
into multi-user mode *and* doesn't stall forever asking the time
(WTF??), configuring a default terminal type so it again stops asking
forever, touching ~/.hushlogin to get rid of a full screen worth of
copyright notices, manually configuring a sane and informative shell
prompt, making root's $HOME something other than "/", and setting the IP
address *inside* the TCP startup script (there is not any variable(s) to
configure in a file to be sourced by said script, incredible!), I can
say it is a nice and stable UNIX, although the userland smells a little
of old...

I am surprised by the "enhanced security subsystems", for accounts,
terminals and files. At first, it was a shock with my test users being
disabled here and there ("Account is disabled -- see Account
Administrator"), and the terminal channels being disabled too ("Terminal
tty03 is disabled"). But I am growing to like it, it feels like a fortress.

I was a little mystified by "passwd -s" declaring as "locked" several
accounts which had perfectly valid encrypted password fields (that is,
no asterisks nor bangs in them, etc.). Then I saw that "passwd" was
interfacing to the "protected password database" to inform about the
lock. However, although "passwd -s" and "passwd -l" do interface to the
"protected password database", that is not the case for "passwd -u",
which I don't quite understand why. I found it confusing so I made these
scripts for my own use:

show-locked-users.sh
#!/bin/sh
# This scrip shows system users with a locked account.
# Created: 2007-07-08.
for var in `cat /etc/passwd | awk -F ":" '{print $1}'` ; \
do passwd -s $var ; done | grep .LK

unlock-given-user.sh
#!/bin/sh
# This script unlocks an user, which it takes a the only parameter.
# The unlock is first done at the shadow file level, then
# at the "OSR5 enhanced security subsystem" level.
# Created: 2007-07-08
[ "$1" = "" ] && echo "Error: no username given.\n\
Usage: you must give one (1) username as parameter, \
so I can unlock it." && exit 1
passwd -u "$1" && usermod -x "{unsuccessfulLoginAttempts 0}" \
-x "{administrativeLockApplied 0}" "$1"


About the terminals locking issue, I have found the "ttylock" and
"ttyunlock" system commands, which work great. However, I have not found
any command to see which tty*'s have fallen under the security lock. I
see I can launch "scoadmin terminal" --> Unlock [Enter] ---> F3, but
that is not a scriptable solution and lacks any elegance (which is to be
expected from a real UNIX).

So, how can I find out from a pure command line which terminals are locked?

Regards,

Pepe.

----- Original Message -----
From: "Pepe" <pepe@naleco.com>
Newsgroups: comp.unix.sco.misc
To: <distro@jpr.com>
Sent: Sunday, July 08, 2007 1:04 PM
Subject: OSR5: how to find out disabled terminals by authorization
subsystem?

[color=blue]
> Hello.
>
> I am giving a test drive to OSR5 (without graphical environment), so far
> so good.
>
> After manually defaulting to the Korn Shell, changing the "intr" code to
> CTRL-C, going through the install with a broken "Spanish" keyboard map,
> setting TIMEOUT=20 in /etc/default/boot so the machine starts directly
> into multi-user mode *and* doesn't stall forever asking the time (WTF??),
> configuring a default terminal type so it again stops asking forever,
> touching ~/.hushlogin to get rid of a full screen worth of copyright
> notices, manually configuring a sane and informative shell prompt, making
> root's $HOME something other than "/", and setting the IP address *inside*
> the TCP startup script (there is not any variable(s) to configure in a
> file to be sourced by said script, incredible!), I can say it is a nice
> and stable UNIX, although the userland smells a little of old...[/color]

You set the IP(s) of the nic(s) by running netconfig.
Further ip related settings like default route and broadcast are set in
/etc/default/tcp (which is indeed sourced by the tcp start script)

You may define further static routes in /usr/internet/etc/sco_ip/routes
May have to create not only the file but the parent dir.
Syntax is like a slightly simplified "route add" command line:
Ex: box has 2 nics, one directly on the net via T1 and the default route
goes out that way. 2nd nic is on a 192.168.33.x lan, and a vpn&nat router
sits on .33.1, which is not already the boxes default route and so vpn
traffic (10.0.0.x) must be forced there with a static route:
---snip---
# net/host gateway destination [mask]
# vpn
net 10.0.0.0 192.168.33.1 255.255.255.0
---snip---

[color=blue]
> I am surprised by the "enhanced security subsystems", for accounts,
> terminals and files. At first, it was a shock with my test users being
> disabled here and there ("Account is disabled -- see Account
> Administrator"), and the terminal channels being disabled too ("Terminal
> tty03 is disabled"). But I am growing to like it, it feels like a
> fortress.
>
> I was a little mystified by "passwd -s" declaring as "locked" several
> accounts which had perfectly valid encrypted password fields (that is, no
> asterisks nor bangs in them, etc.). Then I saw that "passwd" was
> interfacing to the "protected password database" to inform about the lock.
> However, although "passwd -s" and "passwd -l" do interface to the
> "protected password database", that is not the case for "passwd -u", which
> I don't quite understand why. I found it confusing so I made these scripts
> for my own use:
>
> show-locked-users.sh
> #!/bin/sh
> # This scrip shows system users with a locked account.
> # Created: 2007-07-08.
> for var in `cat /etc/passwd | awk -F ":" '{print $1}'` ; \
> do passwd -s $var ; done | grep .LK[/color]

"useless use of cat" award. :)

[color=blue]
> unlock-given-user.sh
> #!/bin/sh
> # This script unlocks an user, which it takes a the only parameter.
> # The unlock is first done at the shadow file level, then
> # at the "OSR5 enhanced security subsystem" level.
> # Created: 2007-07-08
> [ "$1" = "" ] && echo "Error: no username given.\n\
> Usage: you must give one (1) username as parameter, \
> so I can unlock it." && exit 1
> passwd -u "$1" && usermod -x "{unsuccessfulLoginAttempts 0}" \
> -x "{administrativeLockApplied 0}" "$1"
>
>
> About the terminals locking issue, I have found the "ttylock" and
> "ttyunlock" system commands, which work great. However, I have not found
> any command to see which tty*'s have fallen under the security lock. I see
> I can launch "scoadmin terminal" --> Unlock [Enter] ---> F3, but that is
> not a scriptable solution and lacks any elegance (which is to be expected
> from a real UNIX).
>
> So, how can I find out from a pure command line which terminals are
> locked?
>
> Regards,
>
> Pepe.[/color]


Brian K. White [email]brian@aljex.com[/email] [url]http://www.myspace.com/KEYofR[/url]
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

In article <f6r57g$ut8$1@news.ya.com>, Pepe <pepe@naleco.com> wrote:[color=blue]
>show-locked-users.sh[/color]

See also [url]ftp://ftp.armory.com/pub/scripts/lastlogin[/url] - it is a wee bit larger,
but it has some useful options. "lastlogin -A -uk -on" will print the names of
users whose accounts are locked.
[color=blue]
>About the terminals locking issue, I have found the "ttylock" and
>"ttyunlock" system commands, which work great. However, I have not found
>any command to see which tty*'s have fallen under the security lock. I
>see I can launch "scoadmin terminal" --> Unlock [Enter] ---> F3, but
>that is not a scriptable solution and lacks any elegance (which is to be
>expected from a real UNIX).
>
>So, how can I find out from a pure command line which terminals are locked?[/color]

I had an awk function that reads the ttys database, so this was easy:
[url]ftp://ftp.armory.com/pub/user/spcecdt/lockedttys[/url]

John
--
John DuBois [email]spcecdt@armory.com[/email] KC6QKZ/AE [url]http://www.armory.com/~spcecdt/[/url]

John DuBois wrote:
[color=blue][color=green]
>> So, how can I find out from a pure command line which terminals are locked?[/color]
>
> I had an awk function that reads the ttys database, so this was easy:
> [url]ftp://ftp.armory.com/pub/user/spcecdt/lockedttys[/url]
>
> John[/color]

Very interesting. I'll give it a go.

Why wasn't an utility like that shipped with OpenServer 5.0.7 ?

On Jul 8, 3:01 pm, "Brian K. White" <b...@aljex.com> wrote:[color=blue]
> ----- Original Message -----
> From: "Pepe" <p...@naleco.com>
>
> Newsgroups: comp.unix.sco.misc
> To: <dis...@jpr.com>
> Sent: Sunday, July 08, 2007 1:04 PM
> Subject: OSR5: how to find out disabled terminals by authorization
> subsystem?
>[color=green]
> > Hello.[/color]
>[color=green]
> > I am giving a test drive to OSR5 (without graphical environment), so far
> > so good.[/color]
>[color=green]
> > After manually defaulting to the Korn Shell, changing the "intr" code to
> > CTRL-C, going through the install with a broken "Spanish" keyboard map,
> > setting TIMEOUT=20 in /etc/default/boot so the machine starts directly
> > into multi-user mode *and* doesn't stall forever asking the time (WTF??),
> > configuring a default terminal type so it again stops asking forever,
> > touching ~/.hushlogin to get rid of a full screen worth of copyright
> > notices, manually configuring a sane and informative shell prompt, making
> > root's $HOME something other than "/", and setting the IP address *inside*
> > the TCP startup script (there is not any variable(s) to configure in a
> > file to be sourced by said script, incredible!), I can say it is a nice
> > and stable UNIX, although the userland smells a little of old...[/color]
>
> You set the IP(s) of the nic(s) by running netconfig.
> Further ip related settings like default route and broadcast are set in
> /etc/default/tcp (which is indeed sourced by the tcp start script)
>
> You may define further static routes in /usr/internet/etc/sco_ip/routes
> May have to create not only the file but the parent dir.
> Syntax is like a slightly simplified "route add" command line:
> Ex: box has 2 nics, one directly on the net via T1 and the default route
> goes out that way. 2nd nic is on a 192.168.33.x lan, and a vpn&nat router
> sits on .33.1, which is not already the boxes default route and so vpn
> traffic (10.0.0.x) must be forced there with a static route:
> ---snip---
> # net/host gateway destination [mask]
> # vpn
> net 10.0.0.0 192.168.33.1 255.255.255.0
> ---snip---
>[color=green]
> > I am surprised by the "enhanced security subsystems", for accounts,
> > terminals and files. At first, it was a shock with my test users being
> > disabled here and there ("Account is disabled -- see Account
> > Administrator"), and the terminal channels being disabled too ("Terminal
> > tty03 is disabled"). But I am growing to like it, it feels like a
> > fortress.[/color]
>[color=green]
> > I was a little mystified by "passwd -s" declaring as "locked" several
> > accounts which had perfectly valid encrypted password fields (that is, no
> > asterisks nor bangs in them, etc.). Then I saw that "passwd" was
> > interfacing to the "protected password database" to inform about the lock.
> > However, although "passwd -s" and "passwd -l" do interface to the
> > "protected password database", that is not the case for "passwd -u", which
> > I don't quite understand why. I found it confusing so I made these scripts
> > for my own use:[/color]
>[color=green]
> > show-locked-users.sh
> > #!/bin/sh
> > # This scrip shows system users with a locked account.
> > # Created: 2007-07-08.
> > for var in `cat /etc/passwd | awk -F ":" '{print $1}'` ; \
> > do passwd -s $var ; done | grep .LK[/color]
>
> "useless use of cat" award. :)
>[color=green]
> > unlock-given-user.sh
> > #!/bin/sh
> > # This script unlocks an user, which it takes a the only parameter.
> > # The unlock is first done at the shadow file level, then
> > # at the "OSR5 enhanced security subsystem" level.
> > # Created: 2007-07-08
> > [ "$1" = "" ] && echo "Error: no username given.\n\
> > Usage: you must give one (1) username as parameter, \
> > so I can unlock it." && exit 1
> > passwd -u "$1" && usermod -x "{unsuccessfulLoginAttempts 0}" \
> > -x "{administrativeLockApplied 0}" "$1"[/color]
>[color=green]
> > About the terminals locking issue, I have found the "ttylock" and
> > "ttyunlock" system commands, which work great. However, I have not found
> > any command to see which tty*'s have fallen under the security lock. I see
> > I can launch "scoadmin terminal" --> Unlock [Enter] ---> F3, but that is
> > not a scriptable solution and lacks any elegance (which is to be expected
> > from a real UNIX).[/color]
>[color=green]
> > So, how can I find out from a pure command line which terminals are
> > locked?[/color]
>[color=green]
> > Regards,[/color]
>[color=green]
> > Pepe.[/color]
>
> Brian K. White b...@aljex.com [url]http://www.myspace.com/KEYofR[/url]
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro BBx Linux SCO FreeBSD #callahans Satriani Filk![/color]

/usr/internet/etc/sco_ip/routes is not a universal SCO5, and went away
totally in SCO6. I think it's only in the "Fast Start" package.

/etc/default/tcp is sourced by /etc/tcp. If it's a later version of
SCO5 you can define ROUTERDAEMON[0-9] with static routes, e.g.,
ROUTERDAEMON2="/etc/route add 10.3.9.0 -netmask 255.255.255.0
10.3.9.254"
which will be executed by /etc/tcp.

--RLR

On Jul 8, 10:04 am, Pepe <p...@naleco.com> wrote:[color=blue]
> Hello.
>
> I am giving a test drive to OSR5 (without graphical environment), so far
> so good.
>
> After manually defaulting to the Korn Shell, changing the "intr" code to
> CTRL-C, going through the install with a broken "Spanish" keyboard map,
> setting TIMEOUT=20 in /etc/default/boot so the machine starts directly
> into multi-user mode *and* doesn't stall forever asking the time
> (WTF??), configuring a default terminal type so it again stops asking
> forever, touching ~/.hushlogin to get rid of a full screen worth of
> copyright notices, manually configuring a sane and informative shell
> prompt, making root's $HOME something other than "/", and setting the IP
> address *inside* the TCP startup script (there is not any variable(s) to
> configure in a file to be sourced by said script, incredible!), I can
> say it is a nice and stable UNIX, although the userland smells a little
> of old...
>
> I am surprised by the "enhanced security subsystems", for accounts,
> terminals and files. At first, it was a shock with my test users being
> disabled here and there ("Account is disabled -- see Account
> Administrator"), and the terminal channels being disabled too ("Terminal
> tty03 is disabled"). But I am growing to like it, it feels like a fortress.
>
> I was a little mystified by "passwd -s" declaring as "locked" several
> accounts which had perfectly valid encrypted password fields (that is,
> no asterisks nor bangs in them, etc.). Then I saw that "passwd" was
> interfacing to the "protected password database" to inform about the
> lock. However, although "passwd -s" and "passwd -l" do interface to the
> "protected password database", that is not the case for "passwd -u",
> which I don't quite understand why. I found it confusing so I made these
> scripts for my own use:
>
> show-locked-users.sh
> #!/bin/sh
> # This scrip shows system users with a locked account.
> # Created: 2007-07-08.
> for var in `cat /etc/passwd | awk -F ":" '{print $1}'` ; \
> do passwd -s $var ; done | grep .LK
>
> unlock-given-user.sh
> #!/bin/sh
> # This script unlocks an user, which it takes a the only parameter.
> # The unlock is first done at the shadow file level, then
> # at the "OSR5 enhanced security subsystem" level.
> # Created: 2007-07-08
> [ "$1" = "" ] && echo "Error: no username given.\n\
> Usage: you must give one (1) username as parameter, \
> so I can unlock it." && exit 1
> passwd -u "$1" && usermod -x "{unsuccessfulLoginAttempts 0}" \
> -x "{administrativeLockApplied 0}" "$1"
>
> About the terminals locking issue, I have found the "ttylock" and
> "ttyunlock" system commands, which work great. However, I have not found
> any command to see which tty*'s have fallen under the security lock. I
> see I can launch "scoadmin terminal" --> Unlock [Enter] ---> F3, but
> that is not a scriptable solution and lacks any elegance (which is to be
> expected from a real UNIX).
>
> So, how can I find out from a pure command line which terminals are locked?
>
> Regards,
>
> Pepe.[/color]

The time prompt during boot has to do with the fact that SCO5 grew up
in pre-Internet (i.e., pre-NTP) times.

Just comment out the "asktimerc" entry in /etc/inittab. Also in /etc/
conf/cf.d/init.base, from which /etc/inittab is re-constructed from
time to time.

--RLR

In article <1183999976.688524.299000@a26g2000pre.googlegroups.com>,
ThreeStar <sco@3starsoftware.com> wrote:[color=blue]
>On Jul 8, 10:04 am, Pepe <p...@naleco.com> wrote:[color=green]
>> Hello.
>>
>> I am giving a test drive to OSR5 (without graphical environment), so far
>> so good.
>>
>> After manually defaulting to the Korn Shell, changing the "intr" code to
>> CTRL-C, going through the install with a broken "Spanish" keyboard map,
>> setting TIMEOUT=20 in /etc/default/boot so the machine starts directly
>> into multi-user mode *and* doesn't stall forever asking the time
>> (WTF??), configuring a default terminal type so it again stops asking
>> forever, touching ~/.hushlogin to get rid of a full screen worth of
>> copyright notices, manually configuring a sane and informative shell
>> prompt, making root's $HOME something other than "/", and setting the IP
>> address *inside* the TCP startup script (there is not any variable(s) to
>> configure in a file to be sourced by said script, incredible!), I can
>> say it is a nice and stable UNIX, although the userland smells a little
>> of old...
>>
>> I am surprised by the "enhanced security subsystems", for accounts,
>> terminals and files. At first, it was a shock with my test users being
>> disabled here and there ("Account is disabled -- see Account
>> Administrator"), and the terminal channels being disabled too ("Terminal
>> tty03 is disabled"). But I am growing to like it, it feels like a fortress.
>>
>> I was a little mystified by "passwd -s" declaring as "locked" several
>> accounts which had perfectly valid encrypted password fields (that is,
>> no asterisks nor bangs in them, etc.). Then I saw that "passwd" was
>> interfacing to the "protected password database" to inform about the
>> lock. However, although "passwd -s" and "passwd -l" do interface to the
>> "protected password database", that is not the case for "passwd -u",
>> which I don't quite understand why. I found it confusing so I made these
>> scripts for my own use:
>>
>> show-locked-users.sh
>> #!/bin/sh
>> # This scrip shows system users with a locked account.
>> # Created: 2007-07-08.
>> for var in `cat /etc/passwd | awk -F ":" '{print $1}'` ; \
>> do passwd -s $var ; done | grep .LK
>>
>> unlock-given-user.sh
>> #!/bin/sh
>> # This script unlocks an user, which it takes a the only parameter.
>> # The unlock is first done at the shadow file level, then
>> # at the "OSR5 enhanced security subsystem" level.
>> # Created: 2007-07-08
>> [ "$1" = "" ] && echo "Error: no username given.\n\
>> Usage: you must give one (1) username as parameter, \
>> so I can unlock it." && exit 1
>> passwd -u "$1" && usermod -x "{unsuccessfulLoginAttempts 0}" \
>> -x "{administrativeLockApplied 0}" "$1"
>>
>> About the terminals locking issue, I have found the "ttylock" and
>> "ttyunlock" system commands, which work great. However, I have not found
>> any command to see which tty*'s have fallen under the security lock. I
>> see I can launch "scoadmin terminal" --> Unlock [Enter] ---> F3, but
>> that is not a scriptable solution and lacks any elegance (which is to be
>> expected from a real UNIX).
>>
>> So, how can I find out from a pure command line which terminals are locked?
>>
>> Regards,
>>
>> Pepe.[/color][/color]
[color=blue]
>The time prompt during boot has to do with the fact that SCO5 grew up
>in pre-Internet (i.e., pre-NTP) times.[/color]

And also before the systems had built in RTCs to keep track of the
time.

I remember getting a call about 7AM from one company that no one
could log in but the system was running.

I found they had no root password set and they wanted it that way
so anyone could get in.

I explained to them that when the system comes up there was
a press-control-D to continue or enter to go to system. [I think
that was it - it's been a long long time].

So at that point the system was in sinlge user mode. I told them
they must have a root password to prevent mistakes such as that,
and they could post the root password on the computer if they felt
that everyone should have access to that.

So it was a 15 minute call that netted $75. Then I went home and
had breakfast.

Bill
--
Bill Vermillion - bv @ wjv . com

Bill Vermillion wrote:[color=blue]
> In article <1183999976.688524.299000@a26g2000pre.googlegroups.com>,
> ThreeStar <sco@3starsoftware.com> wrote:[color=green]
>> The time prompt during boot has to do with the fact that SCO5 grew up
>> in pre-Internet (i.e., pre-NTP) times.[/color]
>
> And also before the systems had built in RTCs to keep track of the
> time.[/color]

I guess the TRS-80 that ran 16-bit Xenix in 1983 didn't had a RTC, and I
know TCP/IP wasn't a default standard ware with SCO until about 1992
more or less. That's fine, I understand the times and the evolutions.

But OpenServer 5.0.7 was released to market on 2003, so I think it would
have been proper to assume all computers able to run it had battery
backed clocks on the motherboard by then, wouldn't it?

I don't understand why a server operating system shipped in 2003 stops
by default while booting and waits forever for the user to input the
date and time.

My toy machine with Xenix 2.3.4 for the 386 does it, and that's fine,
it's ancient ware, it has an excuse.

Pepe typed (on Thu, Jul 12, 2007 at 01:01:18AM +0200):[color=blue]
> Bill Vermillion wrote:[color=green]
>> In article <1183999976.688524.299000@a26g2000pre.googlegroups.com>,
>> ThreeStar <sco@3starsoftware.com> wrote:[color=darkred]
>>> The time prompt during boot has to do with the fact that SCO5 grew up
>>> in pre-Internet (i.e., pre-NTP) times.[/color]
>> And also before the systems had built in RTCs to keep track of the
>> time.[/color]
>
> I guess the TRS-80 that ran 16-bit Xenix in 1983 didn't had a RTC, and I
> know TCP/IP wasn't a default standard ware with SCO until about 1992 more
> or less. That's fine, I understand the times and the evolutions.
>
> But OpenServer 5.0.7 was released to market on 2003, so I think it would
> have been proper to assume all computers able to run it had battery backed
> clocks on the motherboard by then, wouldn't it?
>
> I don't understand why a server operating system shipped in 2003 stops by
> default while booting and waits forever for the user to input the date and
> time.[/color]
[color=blue]
> My toy machine with Xenix 2.3.4 for the 386 does it, and that's fine, it's
> ancient ware, it has an excuse.[/color]

If you hit ENTER at the boot prompt, yes it will wait forever at the
date prompt.

If you *do nothing* at the boot prompt, the machine will autoboot in
TIMEOUT seconds, and wait TIMEOUT seconds for an answer to the time
prompt too.

If TIMEOUT is not defined in /etc/default/boot, TIMEOUT will default to
60 seconds. I always insert TIMEOUT=6 in /etc/default boot.

--
JP
==> [url]http://www.frappr.com/cusm[/url] <==

In article <f73n8k$mcd$1@news.ya.com>, Pepe <pepe@naleco.com> wrote:[color=blue]
>Bill Vermillion wrote:[color=green]
>> In article <1183999976.688524.299000@a26g2000pre.googlegroups.com>,
>> ThreeStar <sco@3starsoftware.com> wrote:[color=darkred]
>>> The time prompt during boot has to do with the fact that SCO5 grew up
>>> in pre-Internet (i.e., pre-NTP) times.[/color]
>>
>> And also before the systems had built in RTCs to keep track of the
>> time.[/color]
>
>I guess the TRS-80 that ran 16-bit Xenix in 1983 didn't had a RTC, and I
>know TCP/IP wasn't a default standard ware with SCO until about 1992
>more or less. That's fine, I understand the times and the evolutions.
>
>But OpenServer 5.0.7 was released to market on 2003, so I think it would
>have been proper to assume all computers able to run it had battery
>backed clocks on the motherboard by then, wouldn't it?
>
>I don't understand why a server operating system shipped in 2003 stops
>by default while booting and waits forever for the user to input the
>date and time.[/color]

It should NOT wait forever. There is a configurable time-out. But
you don't want to hit any keys during the bootup - as the computer
will 'know' there is someone live at the keyboard and will wait for
input.


--
Bill Vermillion - bv @ wjv . com

ThreeStar wrote:[color=blue]
> On Jul 8, 3:01 pm, "Brian K. White" <b...@aljex.com> wrote:[/color]
[color=blue][color=green]
>> Further ip related settings like default route and broadcast are set in
>> /etc/default/tcp (which is indeed sourced by the tcp start script)
>>
>> You may define further static routes in /usr/internet/etc/sco_ip/routes
>> May have to create not only the file but the parent dir.
>> Syntax is like a slightly simplified "route add" command line:
>> Ex: box has 2 nics, one directly on the net via T1 and the default route
>> goes out that way. 2nd nic is on a 192.168.33.x lan, and a vpn&nat router
>> sits on .33.1, which is not already the boxes default route and so vpn
>> traffic (10.0.0.x) must be forced there with a static route:
>> ---snip---
>> # net/host gateway destination [mask]
>> # vpn
>> net 10.0.0.0 192.168.33.1 255.255.255.0
>> ---snip---
>>[/color]
>
> /usr/internet/etc/sco_ip/routes is not a universal SCO5, and went away
> totally in SCO6. I think it's only in the "Fast Start" package.
>
> /etc/default/tcp is sourced by /etc/tcp. If it's a later version of
> SCO5 you can define ROUTERDAEMON[0-9] with static routes, e.g.,
> ROUTERDAEMON2="/etc/route add 10.3.9.0 -netmask 255.255.255.0
> 10.3.9.254"
> which will be executed by /etc/tcp.[/color]

Both ways (/usr/internet/etc/sco_ip/routes, and ROUTERDAEMONx in
/etc/default/tcp) work on my OpenServer 5.0.7 test system. I certanly
had to manually create the directory "/etc/internet/etc/sco_ip/".

John DuBois wrote:[color=blue]
> In article <f6r57g$ut8$1@news.ya.com>, Pepe <pepe@naleco.com> wrote:[/color]
[color=blue][color=green]
>> About the terminals locking issue, I have found the "ttylock" and
>> "ttyunlock" system commands, which work great. However, I have not found
>> any command to see which tty*'s have fallen under the security lock. I
>> see I can launch "scoadmin terminal" --> Unlock [Enter] ---> F3, but
>> that is not a scriptable solution and lacks any elegance (which is to be
>> expected from a real UNIX).
>>
>> So, how can I find out from a pure command line which terminals are locked?[/color]
>
> I had an awk function that reads the ttys database, so this was easy:
> [url]ftp://ftp.armory.com/pub/user/spcecdt/lockedttys[/url][/color]

I tried to make it work in my OSR-5.0.7 test system, but I guess the GNU gawk
is necessary, so I didn't succeed.

I have finally resorted to a home grown script that will output the TTYs which
are locked, so I can see at the command line the system status regarding locked
TTYs, or put it in a daily cron script to notify me by email or some such.

It is also possible to feed its output to "ttyunlock"(ADM) in the command line:

# ttyunlock `show-locked-ttys.sh` ---> This unlocks all locked TTYs.

This is my script: "show-locked-ttys.sh"

-------------------------SCRIPT BEGINS----------------------------
#!/bin/sh
#
# This script scans the TTY enhanced security database in SCO OpenServer 5.0.7
# and outputs the "tty's" which have been locked by the system security.
# This script takes no parameters.
#
# Created: 2007-07-14

# We can here choose a directory for the temporary files.
MY_TMP_DIR=$HOME
export MY_TMP_DIR
cd $MY_TMP_DIR

# Lets delete the temporary files.
clean() {
cd $MY_TMP_DIR
rm ttys-failed-logins_full.txt ttys-failed-logins_short.txt
}

doit() {
# We find out the maximum errors allowed in the system when logging in at a TTY.
MAX_ERROR_LOGINS=`/etc/userls -D -x maxLoginAttempts | sed -e 's/{//g' -e 's/}//g' | awk ' {print $3}'`
export MAX_ERROR_LOGINS

# Lets create a temporary file with the full details about any TTY where errors have happened at login.
sed -e :mylabel1 -e '/\\$/N; s/\\\n//; tmylabel1' -e 's/#/:/g' /etc/auth/system/ttys | grep t_failures | \
awk 'BEGIN { FS = ":" }; {gsub("\t","",$0); print $0}' > $MY_TMP_DIR/ttys-failed-logins_full.txt

# Lets create a temporary file with only the TTY names where errors have happened at login.
sed -e :mylabel1 -e '/\\$/N; s/\\\n//; tmylabel1' /etc/auth/system/ttys | grep t_failures | \
awk 'BEGIN { FS = ":" }; { print $1}' > $MY_TMP_DIR/ttys-failed-logins_short.txt

# Lets go in a loop to find out how many login errors has any affected TTY. We put it into a variable
# and then we compare it with the system maximum allowed in MAX_ERROR_LOGINS. If higher or equal to it,
# we output the TTY name, because it is a locked TTY.
for var in `cat $MY_TMP_DIR/ttys-failed-logins_short.txt` ; do
TTY_FAILED_LOGINS=`grep $var $MY_TMP_DIR/ttys-failed-logins_full.txt | \
awk -F":" '{for (a=10;a>0;a--) {if ($(NF-a) ~ /t_failures/) print $(NF-(a-1))}}'`
export TTY_FAILED_LOGINS
if [ $TTY_FAILED_LOGINS -ge $MAX_ERROR_LOGINS ] ; then echo $var ; fi
done
}

### MAIN ###
doit
clean
-------------------------SCRIPT ENDS------------------------------


No doubt some guru will come up with a one liner, but I couldn't make it any
better than what is shown above, the requisite being it should work in a stock
OpenServer 5.0.7 system.

Regards,

Pepe.