On Fri, Mar 09, 2007, Jeff Hyman wrote:
>Hello all,
>
> Can anyone explain what the '-R' flag does:
>
>sshd -R
>
>The -R flag is not documented anywhere on man pages.
>OS: SCO 5.0.6

Use the source Luke.

It appears to be used when starting sshd from inetd or xinetd as
it turns on rexeced_flag and inetd_flag.

Bill
--
INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676

When the customer has beaten upon you long enough, give him what he asks
for, instead of what he needs. This is very strong medicine, and is
normally only required once.
-- The Consultant's Curse:

On Mar 8, 2:32 pm, "Dan Martin" <dc.mar...@verizon.net> wrote:
> On Mar 8, 2:44 pm, beetle...@gmail.com wrote:
>
>
>
> > On Mar 8, 12:52 pm, "ThreeStar" <s...@3starsoftware.com> wrote:
>
> > > On Mar 8, 9:44 am, Bill Campbell <b...@celestial.com> wrote:
>
> > > > On Thu, Mar 08, 2007, Jean-Pierre Radley wrote:
> > > > >beetle...@gmail.com typed (on Thu, Mar 08, 2007 at 08:16:07AM -0800):
> > > > >|Onelastquestion.....on DST
> > > > >| When editing a CST TIMEZONE file, I have been using this format:
> > > > >| TZ='CST6CDT,M3.2.0/2,M11.1.0/2'
> > > > >|
> > > > >| But recently I have seen other postings use:
> > > > >| TZ='CST6CDT5,M3.2.0/2,M11.1.0/2'
> > > > >|
> > > > >| Which is correct?
>
> > > > >Eitherone, they are equivalent.
>
> > > > >It is less than obvious that to get the specifics on the construction of
> > > > >the TZ variable you should run 'man environ'.
>
> > > > >There you can read:
>
> > > > > The offset after dst is the difference between local standard
> > > > > time and local summertime. If you do not specify an offset, it
> > > > > is assumed to beonehour. (This is usually what you want.)
>
> > > > >I think that is in error, and what it SHOULD say is that the [optional]
> > > > >offset after dst is the difference from the time at the Prime Meridian,
> > > > >and if this offset is not specified, then it is assumed toonehour less
> > > > >than the offset for standard time.
>
> > > > What processes access the /etc/TIMEZONE file to set TZ?
>
> > > > I don't see anything in /etc/profile or similar startup scripts that would
> > > > be used to set user's environments (OpenServer 5.0.6a and earlier).
>
> > > > I've been appending ``. /etc/TIMEZONE'' to the /etc/profile file when
> > > > updating these systems.
>
> > > > Bill
> > > > --
> > > > INTERNET: b...@Celestial.COM Bill Campbell; Celestial Software LLC
> > > > URL:http://www.celestial.com/POBox820; 6641 E. Mercer Way
> > > > FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
>
> > > > ``Everybody is ignorant, only on different subjects.''
> > > > Will Rogers
>
> > > The init process appears to read /etc/TIMEZONE when it starts up. It
> > > passes TZ on to the shells. Unfortunately it doesn't re-read it when
> > > signaled (telinit). You have to re-boot for changes in it to take
> > > effect.
>
> > > Explicitly including TIMEZONE in /etc/profile is good practice, but
> > > won't ensure that all of init's other children are on the same page.
> > > I've re-booted all systems after changing TIMEZONE.
>
> > > --Ray Robert
>
> > I have also rebooted after making changes. I tested the TIMEZONE edit
> > on a brand new 5.0.7 mp5, rolled the date ahead rebooted and time
> > reflected the change. But when I took itonemore step moving the date
> > ahead to 11/5 the time did not change? Suggestions....comments.
>
> > Thanks!
>
> It worked here. Are you sure you set the time ahead for 11/5?
> Does your initial post contain the exact string of your TZ variable?
>
> Good luck,
> Dan Martin

Dan,

I tried again today...when I move the time ahead to 11/5, it
recognizes the time zone CST but does not roll time.
Do I need to edit the line I am using differently.

TZ='CST6CDT,M3.2.0/2,M11.1.0/2'

Thanks!

On Mar 9, 1:02 pm, beetle.vw@gmail.com wrote:
> On Mar 8, 2:32 pm, "Dan Martin" <dc.mar...@verizon.net> wrote:
>
>
>
> > On Mar 8, 2:44 pm, beetle...@gmail.com wrote:
>
> > > On Mar 8, 12:52 pm, "ThreeStar" <s...@3starsoftware.com> wrote:
>
> > > > On Mar 8, 9:44 am, Bill Campbell <b...@celestial.com> wrote:
>
> > > > > On Thu, Mar 08, 2007, Jean-Pierre Radley wrote:
> > > > > >beetle...@gmail.com typed (on Thu, Mar 08, 2007 at 08:16:07AM -0800):
> > > > > >|Onelastquestion.....on DST
> > > > > >| When editing a CST TIMEZONE file, I have been using this format:
> > > > > >| TZ='CST6CDT,M3.2.0/2,M11.1.0/2'
> > > > > >|
> > > > > >| But recently I have seen other postings use:
> > > > > >| TZ='CST6CDT5,M3.2.0/2,M11.1.0/2'
> > > > > >|
> > > > > >| Which is correct?
>
> > > > > >Eitherone, they are equivalent.
>
> > > > > >It is less than obvious that to get the specifics on the construction of
> > > > > >the TZ variable you should run 'man environ'.
>
> > > > > >There you can read:
>
> > > > > > The offset after dst is the difference between local standard
> > > > > > time and local summertime. If you do not specify an offset, it
> > > > > > is assumed to beonehour. (This is usually what you want.)
>
> > > > > >I think that is in error, and what it SHOULD say is that the [optional]
> > > > > >offset after dst is the difference from the time at the Prime Meridian,
> > > > > >and if this offset is not specified, then it is assumed toonehour less
> > > > > >than the offset for standard time.
>
> > > > > What processes access the /etc/TIMEZONE file to set TZ?
>
> > > > > I don't see anything in /etc/profile or similar startup scripts that would
> > > > > be used to set user's environments (OpenServer 5.0.6a and earlier).
>
> > > > > I've been appending ``. /etc/TIMEZONE'' to the /etc/profile file when
> > > > > updating these systems.
>
> > > > > Bill
> > > > > --
> > > > > INTERNET: b...@Celestial.COM Bill Campbell; Celestial Software LLC
> > > > > URL:http://www.celestial.com/POBox820;6641 E. Mercer Way
> > > > > FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
>
> > > > > ``Everybody is ignorant, only on different subjects.''
> > > > > Will Rogers
>
> > > > The init process appears to read /etc/TIMEZONE when it starts up. It
> > > > passes TZ on to the shells. Unfortunately it doesn't re-read it when
> > > > signaled (telinit). You have to re-boot for changes in it to take
> > > > effect.
>
> > > > Explicitly including TIMEZONE in /etc/profile is good practice, but
> > > > won't ensure that all of init's other children are on the same page.
> > > > I've re-booted all systems after changing TIMEZONE.
>
> > > > --Ray Robert
>
> > > I have also rebooted after making changes. I tested the TIMEZONE edit
> > > on a brand new 5.0.7 mp5, rolled the date ahead rebooted and time
> > > reflected the change. But when I took itonemore step moving the date
> > > ahead to 11/5 the time did not change? Suggestions....comments.
>
> > > Thanks!
>
> > It worked here. Are you sure you set the time ahead for 11/5?
> > Does your initial post contain the exact string of your TZ variable?
>
> > Good luck,
> > Dan Martin
>
> Dan,
>
> I tried again today...when I move the time ahead to 11/5, it
> recognizes the time zone CST but does not roll time.
> Do I need to edit the line I am using differently.
>
> TZ='CST6CDT,M3.2.0/2,M11.1.0/2'
>
> Thanks!

Hello Beetle,

I cut and pasted you TZ line into /etc/TIMEZONE, edited the date/time
with
asktime, and it works fine.

After pasting your TZ variable into /etc/TIMEZONE, I did:

.. /etc/TIMEZONE
# asktime

Current System Time is Fri Mar 9 12:09:10 CST 2007
Enter new time ([[CC]YYMMDD]hhmm[.ss]): 200711040159.55
Sun Nov 4 01:59:55 CDT 2007

# date
Sun Nov 4 01:59:59 CDT 2007
# date
Sun Nov 4 01:00:01 CST 2007

Did you do anything to force a re-read of the TZ variable?
eg, reboot, or

# . /etc/TIMEZONE
# echo $TZ
CST6CDT,M3.2.0/2,M11.1.0/2

Good luck,
Dan Martin

Jeff Hyman wrote (on Fri, Mar 09, 2007 at 12:18:42PM -0500):
> Hello all,
>
> Can anyone explain what the '-R' flag does:
>
> sshd -R
>
> The -R flag is not documented anywhere on man pages.
> OS: SCO 5.0.6
>
> root 1695 1 0 Feb-07 ? 00:00:02 /usr/local/sbin/sshd
> root 1021 1695 0 11:06:49 ? 00:00:04 /usr/local/sbin/sshd -R
>
> TIA,
> - Jeff Hyman

I found this on Google:

http://www.derkeiler.com/Newsgroups/...5-03/0282.html

"It indicates that the sshd process was started by another sshd (or by
inetd)."

Follow the thread to get to:
http://groups.google.com/group/maili...8d441294b7bb02

"Starting with 3.9x, sshd will re-exec itself for every connection.
This means that any exec-time process randomization (eg library offsets,
propolice canaries) will be different for each connection. (For a
thorough overview of what OpenBSD does, see [1]. Most platforms don't
have these, however this will hopefully change over time, for example if
the propolice patches get integrated into gcc).

"sshd needs to do some things a little differently after it's re-execed
itself. -R is an internal flag that causes those changes in behaviour."


--
_________________________________________
Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
Attorney and Counselor-at-Law http://ziskind.us
Economic Group Pension Services http://egps.com
Actuaries and Employee Benefit Consultants

Jeff Hyman typed (on Fri, Mar 09, 2007 at 12:18:42PM -0500):
| Can anyone explain what the '-R' flag does:
|
| sshd -R
|
| The -R flag is not documented anywhere on man pages.
| OS: SCO 5.0.6
|
| root 1695 1 0 Feb-07 ? 00:00:02 /usr/local/sbin/sshd
| root 1021 1695 0 11:06:49 ? 00:00:04 /usr/local/sbin/sshd -R
|

I don't think it's a meaningful user flag at all.

I do see it in the output of the 'ps' command for every single child of
the initial sshd daemon.

IOW, process 1695 is the sshd daemon that started on Feb 7, no doubt
when you last rebooted the machine, while process 1021 is a child of that
daemon, forked a couple of hours ago for a still-active ssh connection.

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

In article <1173379957.805577.238230@v33g2000cwv.googlegroups .com>,
ThreeStar <sco@3starsoftware.com> wrote:
>The init process appears to read /etc/TIMEZONE when it starts up. It
>passes TZ on to the shells. Unfortunately it doesn't re-read it when
>signaled (telinit). You have to re-boot for changes in it to take
>effect.

init spawns all of its children by executing them via /etc/initscript.
initscript sources /etc/TIMEZONE before executing the specified program.
So, changes to TIMEZONE will affect any processes spawned by init after
TIMEZONE is changed. Of course, this won't have any effect on already
running processes.

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

beetle.vw@gmail.com wrote:
> On Mar 8, 12:52 pm, "ThreeStar" <s...@3starsoftware.com> wrote:
>> On Mar 8, 9:44 am, Bill Campbell <b...@celestial.com> wrote:
>>
>>
>>
>>> On Thu, Mar 08, 2007, Jean-Pierre Radley wrote:
>>>> beetle...@gmail.com typed (on Thu, Mar 08, 2007 at 08:16:07AM -0800):
>>>> | One last question.....on DST
>>>> | When editing a CST TIMEZONE file, I have been using this format:
>>>> | TZ='CST6CDT,M3.2.0/2,M11.1.0/2'
>>>> |
>>>> | But recently I have seen other postings use:
>>>> | TZ='CST6CDT5,M3.2.0/2,M11.1.0/2'
>>>> |
>>>> | Which is correct?
>>>> Either one, they are equivalent.
>>>> It is less than obvious that to get the specifics on the construction of
>>>> the TZ variable you should run 'man environ'.
>>>> There you can read:
>>>> The offset after dst is the difference between local standard
>>>> time and local summertime. If you do not specify an offset, it
>>>> is assumed to be one hour. (This is usually what you want.)
>>>> I think that is in error, and what it SHOULD say is that the [optional]
>>>> offset after dst is the difference from the time at the Prime Meridian,
>>>> and if this offset is not specified, then it is assumed to one hour less
>>>> than the offset for standard time.
>>> What processes access the /etc/TIMEZONE file to set TZ?
>>> I don't see anything in /etc/profile or similar startup scripts that would
>>> be used to set user's environments (OpenServer 5.0.6a and earlier).
>>> I've been appending ``. /etc/TIMEZONE'' to the /etc/profile file when
>>> updating these systems.
>>> Bill
>>> --
>>> INTERNET: b...@Celestial.COM Bill Campbell; Celestial Software LLC
>>> URL:http://www.celestial.com/PO Box 820; 6641 E. Mercer Way
>>> FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
>>> ``Everybody is ignorant, only on different subjects.''
>>> Will Rogers
>> The init process appears to read /etc/TIMEZONE when it starts up. It
>> passes TZ on to the shells. Unfortunately it doesn't re-read it when
>> signaled (telinit). You have to re-boot for changes in it to take
>> effect.
>>
>> Explicitly including TIMEZONE in /etc/profile is good practice, but
>> won't ensure that all of init's other children are on the same page.
>> I've re-booted all systems after changing TIMEZONE.
>>
>> --Ray Robert
>
> I have also rebooted after making changes. I tested the TIMEZONE edit
> on a brand new 5.0.7 mp5, rolled the date ahead rebooted and time
> reflected the change. But when I took it one more step moving the date
> ahead to 11/5 the time did not change? Suggestions....comments.
>
> Thanks!
>
>

Hmm.

The TZ edit should not be needed on 5.0.7 with MP5 applied. MP5 includes
the DST patch.

Perhaps adding the /etc/TIMEZONE edit to a system with MP5 also applied
is confusing 5.0.7?

--
----------------------------------------------------
Pat Welch, UBB Computer Services, a WCS Affiliate
SCO Authorized Partner
Unix/Linux/Windows/Hardware Sales/Support
(209) 745-1401 Cell: (209) 251-9120
E-mail: patubb@inreach.com
----------------------------------------------------

Pat Welch typed (on Sat, Mar 10, 2007 at 02:28:47PM -0800):
|
| The TZ edit should not be needed on 5.0.7 with MP5 applied. MP5 includes
| the DST patch.
|
| Perhaps adding the /etc/TIMEZONE edit to a system with MP5 also applied
| is confusing 5.0.7?

No, it isn't confusing in the least.

It means that if you are looking for the HH:MM timestamp of a file last
modified on, say, March 15, 2006 (e.g., using the 'l -T' comand), you'll
get the correct value if you leave the short form of TZ, but if you
insist on using the long form, than that time will be an hour off, since
you've insisted on using the 2007 DST rules even for older files.

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

Jean-Pierre Radley typed (on Fri, Mar 09, 2007 at 12:48:45PM -0500):
| Jeff Hyman typed (on Fri, Mar 09, 2007 at 12:18:42PM -0500):
| | Can anyone explain what the '-R' flag does:
| |
| | sshd -R
| |
| | The -R flag is not documented anywhere on man pages.
| | OS: SCO 5.0.6
| |
| | root 1695 1 0 Feb-07 ? 00:00:02 /usr/local/sbin/sshd
| | root 1021 1695 0 11:06:49 ? 00:00:04 /usr/local/sbin/sshd -R
| |
|
| I don't think it's a meaningful user flag at all.
|
| I do see it in the output of the 'ps' command for every single child of
| the initial sshd daemon.
|
| IOW, process 1695 is the sshd daemon that started on Feb 7, no doubt
| when you last rebooted the machine, while process 1021 is a child of that
| daemon, forked a couple of hours ago for a still-active ssh connection.
|
| --
| JP
| ==> http://www.frappr.com/cusm <==

Thanks JP and the others that replied.
Always appreciated!

- Jeff Hyman

In article <20070310225505.GJ2604@jpradley.jpr.com>,
Jean-Pierre Radley <jpr@jpr.com> wrote:
>Pat Welch typed (on Sat, Mar 10, 2007 at 02:28:47PM -0800):
>|
>| The TZ edit should not be needed on 5.0.7 with MP5 applied. MP5 includes
>| the DST patch.
>|
>| Perhaps adding the /etc/TIMEZONE edit to a system with MP5 also applied
>| is confusing 5.0.7?
>
>No, it isn't confusing in the least.
>
>It means that if you are looking for the HH:MM timestamp of a file last
>modified on, say, March 15, 2006 (e.g., using the 'l -T' comand), you'll
>get the correct value if you leave the short form of TZ, but if you
>insist on using the long form, than that time will be an hour off, since
>you've insisted on using the 2007 DST rules even for older files.

All true. It is worth noting, though, that if you have old static
non-shared-library binaries, they won't get the library fix, and so will
not know about the DST change unless you use the long version of TZ, at least
for them.

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