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

This is a discussion on OSR5: how to find out disabled terminals by authorization subsystem? - SCO ; 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 ...

+ Reply to Thread
Results 1 to 12 of 12

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

  1. 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.

  2. Re: how to find out disabled terminals by authorization subsystem?


    ----- Original Message -----
    From: "Pepe"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Sunday, July 08, 2007 1:04 PM
    Subject: 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...


    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---


    > 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


    "useless use of cat" award.


    > 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.



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


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

    In article , Pepe wrote:
    >show-locked-users.sh


    See also ftp://ftp.armory.com/pub/scripts/lastlogin - 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.

    >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?


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

    John
    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

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

    John DuBois wrote:

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

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


    Very interesting. I'll give it a go.

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

  5. Re: how to find out disabled terminals by authorization subsystem?

    On Jul 8, 3:01 pm, "Brian K. White" wrote:
    > ----- Original Message -----
    > From: "Pepe"
    >
    > Newsgroups: comp.unix.sco.misc
    > To:
    > Sent: Sunday, July 08, 2007 1:04 PM
    > Subject: 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...

    >
    > 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---
    >
    > > 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

    >
    > "useless use of cat" award.
    >
    > > 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.

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


    /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


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

    On Jul 8, 10:04 am, Pepe wrote:
    > 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.


    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


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

    In article <1183999976.688524.299000@a26g2000pre.googlegroups. com>,
    ThreeStar wrote:
    >On Jul 8, 10:04 am, Pepe wrote:
    >> 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.


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


    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

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

    Bill Vermillion wrote:
    > In article <1183999976.688524.299000@a26g2000pre.googlegroups. com>,
    > ThreeStar wrote:
    >> The time prompt during boot has to do with the fact that SCO5 grew up
    >> in pre-Internet (i.e., pre-NTP) times.

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


    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.

  9. Re: OSR5: how to find out disabled terminals by authorization

    Pepe typed (on Thu, Jul 12, 2007 at 01:01:18AM +0200):
    > Bill Vermillion wrote:
    >> In article <1183999976.688524.299000@a26g2000pre.googlegroups. com>,
    >> ThreeStar wrote:
    >>> The time prompt during boot has to do with the fact that SCO5 grew up
    >>> in pre-Internet (i.e., pre-NTP) times.

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

    >
    > 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.


    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
    ==> http://www.frappr.com/cusm <==

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

    In article , Pepe wrote:
    >Bill Vermillion wrote:
    >> In article <1183999976.688524.299000@a26g2000pre.googlegroups. com>,
    >> ThreeStar wrote:
    >>> The time prompt during boot has to do with the fact that SCO5 grew up
    >>> in pre-Internet (i.e., pre-NTP) times.

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

    >
    >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.


    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

  11. Re: how to find out disabled terminals by authorization subsystem?

    ThreeStar wrote:
    > On Jul 8, 3:01 pm, "Brian K. White" wrote:


    >> 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---
    >>

    >
    > /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.


    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/".

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

    John DuBois wrote:
    > In article , Pepe wrote:


    >> 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?

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


    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.

+ Reply to Thread