Re: [gentoo-user] Two issues with OpenRC/baselayout2 migration on a hosted VM

[victor romanchuk]

Pandu Poluan wrote, at 12/13/2011 10:26 PM:
>
>
> On Dec 14, 2011 1:06 AM, "Tanstaafl"  > wrote:
> >
> > What should I set this to? Assuming that Linode is indeed using Xen, would
> it be:
> >
> > rc_sys="xenU"
> >
> > ?
>
> AFAIK Linode uses Xen so "xenU" is correct.
>
> What I really want to know is what happens if we specify a 'wrong' rc_sys 
> value...
>
> (I also want to know why 'rc -S' is so unhelpful, but not as much as the 
> above.)
>

i have looked through openrc sources and experimented a bit; the idea of rc_sys
is simple: the contents of that variable affects 'keyword' dependencies in
/etc/init.d/ scripts. the feature is documented, see runscript(8) for details,
but apparently does not work as expected. i also did not find valuable 'keyword'
dependencies in software packages i use thus considered that rc_sys might be set
to any value with no side effects

another thing i found is an $RC_SYS environment variable available to all
scripts initiated by rc; that one is set to value defined in /etc/rc.conf or
automatically detected if rc_sys is not explicitly set. the automatic detection
is trivial, eg. if the directory "/proc/xen" does exist, then $SYS_RC is set to
XENU. setting of $SYS_RC to XEN0 would be in case of "/proc/xen" existence and
if contents of the file /proc/xen/capabilities is equal to "control-d". all that
stuff could be found in src/librc/librc.c

i'm using $RC_SYS as a flag controlling start of xen dom0 daemons: rc_sys is
commented out in /etc/rc.conf to let runscript autodetect the environment. all
xen related stuff is started from /etc/local.d, like that:

$ cat /etc/local.d/xen.start
if [ "x$RC_SYS" = "xXEN0" ]; then
# start xenstored, xenconsole, configure xen networking etc
else
# do something else related to baremetal os boot
fi

this slightly speeds up boot process and produces more clear logs

Re: [gentoo-user] Two issues with OpenRC/baselayout2 migration on a hosted VM

[Neil Bothwick]

On Tue, 13 Dec 2011 15:42:01 -0500, Tanstaafl wrote:

> > The files were named local.{start,stop} but the message you quoted
> > shows that these are no longer the case. The files you have are your
> > old baselayout1 local.* files moved from conf.d to local.d and given
> > a name that shows where they came from. The local part of the
> > filename is no longer relevant as the directory name makes their
> > purpose clear. Also, it means you can have more than one file,
> > instead of having to cram several unrelated steps into one script.
> >
> > Give them names that reflect their contents, it will make managing
> > them easier.  
> 
> Yes, but - I'm no longer on baselayout1, so that name is no longer 
> accurate...

The name is accurate because it is telling you the file came from
baselayout1. The local.{start,stop} names are the deprecated names used
by BL1. Until you give them more meaningful names (which local.* are not)
baselayout1.* are the best names portage can give them for you.


-- 
Neil Bothwick

All right, set phasers to deep fat fry!


signature.asc
Description: PGP signature

Re: [gentoo-user] Two issues with OpenRC/baselayout2 migration on a hosted VM

[Tanstaafl]

On 2011-12-13 3:21 PM, Neil Bothwick  wrote:

On Tue, 13 Dec 2011 14:50:06 -0500, Tanstaafl wrote:


Problem - on this VM, these files are named 'baselayout1.start' and
'baselayout1.stop', NOT 'local.start' and 'local.stop'...

Should I change these? Does it matter?



The names doesn't matter. Only the extension matters. You can even
rename them to MickeyMouse.start and MinnieMouse.stop :-)


Ok, thanks, renamed to local.start/stop...


The files were named local.{start,stop} but the message you quoted shows
that these are no longer the case. The files you have are your old
baselayout1 local.* files moved from conf.d to local.d and given a name
that shows where they came from. The local part of the filename is no
longer relevant as the directory name makes their purpose clear. Also, it
means you can have more than one file, instead of having to cram several
unrelated steps into one script.

Give them names that reflect their contents, it will make managing them
easier.


Yes, but - I'm no longer on baselayout1, so that name is no longer 
accurate...

Re: [gentoo-user] Two issues with OpenRC/baselayout2 migration on a hosted VM

[Neil Bothwick]

On Tue, 13 Dec 2011 14:50:06 -0500, Tanstaafl wrote:

> >> Problem - on this VM, these files are named 'baselayout1.start' and
> >> 'baselayout1.stop', NOT 'local.start' and 'local.stop'...
> >>
> >> Should I change these? Does it matter?  
> 
> > The names doesn't matter. Only the extension matters. You can even
> > rename them to MickeyMouse.start and MinnieMouse.stop :-)  
> 
> Ok, thanks, renamed to local.start/stop...

The files were named local.{start,stop} but the message you quoted shows
that these are no longer the case. The files you have are your old
baselayout1 local.* files moved from conf.d to local.d and given a name
that shows where they came from. The local part of the filename is no
longer relevant as the directory name makes their purpose clear. Also, it
means you can have more than one file, instead of having to cram several
unrelated steps into one script.

Give them names that reflect their contents, it will make managing them
easier.


-- 
Neil Bothwick

Member, National Association For Tagline Assimilators (NAFTA)


signature.asc
Description: PGP signature

Re: [gentoo-user] Two issues with OpenRC/baselayout2 migration on a hosted VM

[Tanstaafl]

On 2011-12-13 1:26 PM, Pandu Poluan  wrote:

Problem - on this VM, these files are named 'baselayout1.start' and
'baselayout1.stop', NOT 'local.start' and 'local.stop'...

Should I change these? Does it matter?



The names doesn't matter. Only the extension matters. You can even
rename them to MickeyMouse.start and MinnieMouse.stop :-)


Ok, thanks, renamed to local.start/stop...


AFAIK Linode uses Xen so "xenU" is correct.


Cool, thanks... crossing fingers until the reboot...

Re: [gentoo-user] Two issues with OpenRC/baselayout2 migration on a hosted VM

[Pandu Poluan]

On Dec 14, 2011 1:06 AM, "Tanstaafl"  wrote:
>
> Hello,
>
> This is my first time dealing with a VM, and this one is being hosted on
Linode... I'm fairly sure they use XenServer, but I'm still waiting for
confirmation...
>
> 2 issues I have after updating:
>
> 1. First question
>
> Quoting from the Guide:
>
> "local.start and local.stop
>
> With OpenRC, /etc/conf.d/local.start and local.stop are deprecated.
During the migration to OpenRC, the files are moved to /etc/local.d and
gain the suffix .start or .stop. OpenRC then executes those in alphabetic
order."
>
> Problem - on this VM, these files are named 'baselayout1.start' and
'baselayout1.stop', NOT 'local.start' and 'local.stop'...
>
> Should I change these? Does it matter?
>

The names doesn't matter. Only the extension matters. You can even rename
them to MickeyMouse.start and MinnieMouse.stop :-)

> 2. Second question
>
> Quoting from the Guide:
>
> "System sub-types: Virtualization special cases
>
> In the early versions of OpenRC, we explictly detected multiple types of
virtualization, and used that detection to note when certain init scripts
should be skipped, using the keyword call in the depend functions.
>
> However, as of the 0.7.0 release, you are required to explicitly
configure the sub-type using the rc_sys variable in /etc/rc.conf. The
sub-type should be set to match the virtualization environment that the
given root is in. In general, the non-empty rc_sys value should be within
the virtual containers; The host node will have rc_sys="".
>
> Important: If you do not have any specific sub-type, please use the
default of an empty string "". If the variable is unset, you will be given
a warning and we will attempt to use the old detection algorithm.
>
> Note: If you do not know what value your system was using with the
automatic detection, you should temporarily comment out the rc_sys variable
and run the detection command, rc -S."
>
> Currently this is set to "", but according to the guide, since this is a
VM, it needs to be explicitly set. rc -S simply reports:
>
> "li66-207 etc # rc -S
> * WARNING: rc_sys not defined in rc.conf. Falling back to automatic
detection"
>
> What should I set this to? Assuming that Linode is indeed using Xen,
would it be:
>
> rc_sys="xenU"
>
> ?
>

AFAIK Linode uses Xen so "xenU" is correct.

What I really want to know is what happens if we specify a 'wrong' rc_sys
value...

(I also want to know why 'rc -S' is so unhelpful, but not as much as the
above.)

Rgds,

[gentoo-user] Two issues with OpenRC/baselayout2 migration on a hosted VM

[Tanstaafl]

Hello,

This is my first time dealing with a VM, and this one is being hosted on 
Linode... I'm fairly sure they use XenServer, but I'm still waiting for 
confirmation...


2 issues I have after updating:

1. First question

Quoting from the Guide:

"local.start and local.stop

With OpenRC, /etc/conf.d/local.start and local.stop are deprecated. 
During the migration to OpenRC, the files are moved to /etc/local.d and 
gain the suffix .start or .stop. OpenRC then executes those in 
alphabetic order."


Problem - on this VM, these files are named 'baselayout1.start' and 
'baselayout1.stop', NOT 'local.start' and 'local.stop'...


Should I change these? Does it matter?

2. Second question

Quoting from the Guide:

"System sub-types: Virtualization special cases

In the early versions of OpenRC, we explictly detected multiple types of 
virtualization, and used that detection to note when certain init 
scripts should be skipped, using the keyword call in the depend functions.


However, as of the 0.7.0 release, you are required to explicitly 
configure the sub-type using the rc_sys variable in /etc/rc.conf. The 
sub-type should be set to match the virtualization environment that the 
given root is in. In general, the non-empty rc_sys value should be 
within the virtual containers; The host node will have rc_sys="".


Important: If you do not have any specific sub-type, please use the 
default of an empty string "". If the variable is unset, you will be 
given a warning and we will attempt to use the old detection algorithm.


Note: If you do not know what value your system was using with the 
automatic detection, you should temporarily comment out the rc_sys 
variable and run the detection command, rc -S."


Currently this is set to "", but according to the guide, since this is a 
VM, it needs to be explicitly set. rc -S simply reports:


"li66-207 etc # rc -S
* WARNING: rc_sys not defined in rc.conf. Falling back to automatic 
detection"


What should I set this to? Assuming that Linode is indeed using Xen, 
would it be:


rc_sys="xenU"

?

Thanks,

Charles