[gentoo-user] Re: openrc-run for containers

[Damo]

Correction: the *s6_service_path* parameter in the parent init.d service,
/etc/init.d/container, needs to be changed from
/run/openrc/s6-scan/${INSTANCE} to /var/svc.d/${INSTANCE}





*#!/sbin/openrc-rundescription="A supervised test service with a
logger"supervisor=s6**s6_service_path=/var/svc.d/${INSTANCE}*

*depend() {*
*   need s6-svscan*
*}*

*stop_pre() {*
*  docker stop ${INSTANCE}*
*}*

NB; In runlevels, dont need to include s6-svscan. Only need to include the
service to start (s6-svscan will start as a service dependency).

Further info (go from runlevel 90 > 100 > back to 90):

root@/etc/runlevels #
* ls -ld node/*lrwxrwxrwx 1 root root 24 May 25 06:17 100/container.whoami
-> /etc/init.d/container.*whoami
*lrwxrwxrwx 1 root root 11 Jan 15 04:32 100/90 -> ../90*


*root@/etc/runlevels # openrc 100container.*whoami*  |/var/svc.d/*whoami
*container.*whoami*  | * Starting container.*whoami* ...*






*
  [ ok ]root@h003
/e/runlevels # docker ps -aCONTAINER ID   IMAGE
 COMMAND  CREATEDSTATUS
   PORTS  NAMES68bd2ed585ed
traefik/whoami "/whoami"
 25 hours ago   Up 1 minute 0.0.0.0:80->80/tcp
whoamiroot@/e/runlevels # openrc 90container.*whoami*
 |/var/svc.d/*whoami
*container.*whoami*  |*whoami
*container.*whoami* | * Stopping container.*whoami* ...

[ ok ]*





*root@/etc/runlevels # docker ps -aCONTAINER ID   IMAGE
 COMMAND  CREATED
 STATUSPORTS  NAMES68bd2ed585ed
  traefik/whoami "/whoami"
   25 hours ago   Exited (143) 8 seconds ago
0.0.0.0:80->80/tcp whoamiroot@/etc/runlevels # *


regs,

On Thu, May 13, 2021 at 5:17 AM Damo  wrote:

> Hi,
>
> I've been running docker containers for a while, where I pass
> "--restart=always" into the run command, so the containers restart
> automatically after reboot. I want to have more control over the startup
> order of the containers, ie integrate into openrc start/stop and put into
> different runlevels.
>
> I've had mixed success so far. I would be interested if someone else has
> working solution. My runlevels look something like this:
>
> rl100
>   container.registry
> rl90
>   container.auth
>   container.router
> boot
>  ...
>
> FYI, i've found systemd is doing it nicely, where systemctl start/stop
>  works as I would expect. I see a hardcoded dependency into the
> container PID in the unit file (podman in this case):
>
> [root@]# cat /usr/lib/systemd/system/container-libvirt-exporter.service
>
> #
>
> [Unit]
> Description=Podman container-libvirtd-exporter.service
> Documentation=man:podman-generate-systemd(1)
>
> [Service]
> Restart=always
> ExecStart=/usr/bin/podman start libvirtd-exporter
> ExecStop=/usr/bin/podman stop -t 10 libvirtd-exporter
> KillMode=none
> Type=forking
>
> PIDFile=/var/run/containers/storage/overlay-containers/9037e389e61ed01eb5dfce16fa750b6f0f01827a67640e4748e6527bbfcb6276/userdata/conmon.pid
>
> [Install]
> WantedBy=multi-user.target
>
>
> Kind regards,
> Damo
>
>

[gentoo-user] Re: openrc-run for containers

[Damo]

Hi,

I've got the integration working how I imagined. It is using s6-svscan to
manage the containers, hopefully not abusing something. General idea is to
have supervision control over containers, ie to allow start up in a given
runlevel, have the ability to manage dependency start between given
containers and start/stop using openrc (referenced
https://wiki.gentoo.org/wiki/S6).

Assuming containers are already running, ie given instance of whoami
container:

*docker run -p 80:80 -d -it --name whoami traefik/whoami*

The "run" script, /var/svc.d/whoami/run:

#!/bin/execlineb -P
exec docker start -a whoami

The "finish" script, /var/svc.d/whoami/finish


*#!/bin/execlineb -Ps6-permafailon 60 1 2 exit*

The init.d, conf.d. Cat /etc/conf.d/container.whoami:

*INSTANCE=whoami*

Cat /etc/init.d/container:












*#!/sbin/openrc-rundescription="A supervised test service with a
logger"supervisor=s6s6_service_path=/run/openrc/s6-scan/${INSTANCE}depend()
{   need s6-svscan}stop_pre() {  docker stop ${INSTANCE}}*

Finally, [openrc-run, ln -s /etc/init.d/container
/etc/init.d/container.whoami] /etc/initd.d/container.whoami start, stop
work as expected (docker ps |grep whoami does not return anything, after
running "/etc/init.d/container.whoami stop"):

List containers
root@ # *docker ps |grep whoami*
68bd2ed585ed   traefik/whoami
  "/whoami"35 minutes ago   Up 34 minutes
0.0.0.0:80->80/tcp whoami

root@ # *./container.whoami stop*
container.whoami   |whoami
container.whoami   | * Stopping container.whoami ...

 [ ok ]

root@ # *docker ps |grep whoami*

root@ #* ./container.whoami start*
container.whoami   | * Starting container.whoami ...

 [ ok ]
root@ # docker ps |grep whoami
68bd2ed585ed   traefik/whoami
  "/whoami"35 minutes ago   Up 3 seconds
 0.0.0.0:80->80/tcp whoami

root@ # *ps xf -o pid,ppid,pgrp,euser,args*
  PID  PPID  PGRP EUSERCOMMAND
21056 1 21056 root /bin/s6-svscan /run/openrc/s6-scan
21058 21056 21056 root  \_ s6-supervise whoami/log
21059 21056 21056 root  \_ s6-supervise whoami
27584 21059 27584 root  |   \_ docker start -a whoami

Similar to above, using s6-svstat:

root@ # *s6-svstat /run/openrc/s6-scan/whoami*
up (pid 27584) 752 seconds

root@ # *./container.whoami stop*
container.whoami   |whoami
container.whoami   | * Stopping container.whoami ...

 [ ok ]

root@ #* s6-svstat /run/openrc/s6-scan/whoami*
down (exitcode 2) 1 seconds, normally up, ready 1 seconds

root@ #* ./container.whoami start*
container.whoami   | * Starting container.whoami ...

 [ ok ]
root@h003 /e/init.d # s6-svstat /run/openrc/s6-scan/whoami
up (pid 6722) 3 seconds

The goal of all this has been to incorporate containers into
/etc/runlevels. I am not sure if there is a better way, have I missed
something by not using s6-overlay or the like? I am not familiar enough to
know.

An outstanding issue, in the s6 run script, i would like to parametrize the
instance name, I don't know how to do it, as it is currently hard coded:

The "run" script, /var/svc.d/whoami/run:

#!/bin/execlineb -P
exec docker start -a *whoami*

But once that is done, then all running containers could be incorporated by
updating the conf.d for INSTANCE name, templating a /var/svc.d/
folder and linking to /etc/init.d/container, ie:

/etc/init.d/container.whoami
/etc/init.d/container.cadvisor
/etc/init.d/container.traefik

[put under control of s6]
/etc/runlevels/20/s6-svscan
...

This is kind of asymmetric, ie container start is in s6, whereas stop
[docker] is in openrc, but I am not seeing a different way, the goal is to
have robust services running. When system boots, s6-scan will start all the
containers automatically, but then further operations, ie for things like
manual failover etc, is possible using standard platform openrc -
effectively docker - start/stop commands.


kind regards




On Thu, May 13, 2021 at 5:17 AM Damo  wrote:

> Hi,
>
> I've been running docker containers for a while, where I pass
> "--restart=always" into the run command, so the containers restart
> automatically after reboot. I want to have more control over the startup
> order of the containers, ie integrate into openrc start/stop and put into
> different runlevels.
>
> I've had mixed success so far. I would be interested if someone else has
> working solution. My runlevels look something like this:
>
> rl100
>   container.registry
> rl90
>   container.auth
>   container.router
> boot
>  ...
>
> FYI, i've found systemd is doing it nicely, where systemctl start/stop
>  works as I would expect. I see a hardcoded dependency into the
> container PID in the unit file (podman in this case):
>
> [root@]# cat /usr/lib/systemd/system/container-libvirt-exporter.service
>
> #
>
> [Unit]
> Description=Podman con

[gentoo-user] openrc-run for containers

[Damo]

Hi,

I've been running docker containers for a while, where I pass
"--restart=always" into the run command, so the containers restart
automatically after reboot. I want to have more control over the startup
order of the containers, ie integrate into openrc start/stop and put into
different runlevels.

I've had mixed success so far. I would be interested if someone else has
working solution. My runlevels look something like this:

rl100
  container.registry
rl90
  container.auth
  container.router
boot
 ...

FYI, i've found systemd is doing it nicely, where systemctl start/stop
 works as I would expect. I see a hardcoded dependency into the
container PID in the unit file (podman in this case):

[root@]# cat /usr/lib/systemd/system/container-libvirt-exporter.service

#

[Unit]
Description=Podman container-libvirtd-exporter.service
Documentation=man:podman-generate-systemd(1)

[Service]
Restart=always
ExecStart=/usr/bin/podman start libvirtd-exporter
ExecStop=/usr/bin/podman stop -t 10 libvirtd-exporter
KillMode=none
Type=forking
PIDFile=/var/run/containers/storage/overlay-containers/9037e389e61ed01eb5dfce16fa750b6f0f01827a67640e4748e6527bbfcb6276/userdata/conmon.pid

[Install]
WantedBy=multi-user.target


Kind regards,
Damo

Re: [gentoo-user] Annoying mapping of some keys

[Damo Brisbane]

Under X, xmodmap  perhaps?

On Sun, May 20, 2018 at 6:17 PM, Klaus Ethgen 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> I have an annoying problem on gentoo that I work around currently by
> using zkbd from zsh.
>
> Some keys on Gentoo, on xterm, console and via ssh from remote host, map
> to wrong keycodes. Namely and most important, that are the keys for
> begin, end and delete. They insert a tilde char instead of doing the
> expected cursor movement.
>
> A correct table would show as following:
>key[F1]='^[OP'
>key[F2]='^[OQ'
>key[F3]='^[OR'
>key[F4]='^[OS'
>key[F5]='^[[15~'
>key[F6]='^[[17~'
>key[F7]='^[[18~'
>key[F8]='^[[19~'
>key[F9]='^[[20~'
>key[F10]='^[[21~'
>key[F11]='^[[23~'
>key[F12]='^[[24~'
>key[Backspace]='^?'
>key[Insert]='^[[2~'
>key[Home]='^[[H'
>key[PageUp]='^[[5~'
>key[Delete]='^[[3~'
>key[End]='^[[F'
>key[PageDown]='^[[6~'
>key[Up]='^[[A'
>key[Left]='^[[D'
>key[Down]='^[[B'
>key[Right]='^[[C'
>key[Menu]=
>
> Is there any way to fix that system wide in Gentoo?
>
> Regards
>Klaus
> - --
> Klaus Ethgen   http://www.ethgen.ch/
> pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
> Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
> -BEGIN PGP SIGNATURE-
> Comment: Charset: ISO-8859-1
>
> iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlsBLy8ACgkQpnwKsYAZ
> 9qx9QQwAw/8vCYNcjBJS4+Q6FcSAXg/Kx25DtcET7Q+GngwWJMafex0+ySD1p+za
> O5zUo1auePNuziFL6U6+f3m+/z/uHonIoUZ3Fqk1I/0xzD3QUmUDouzv/RwhD5N8
> W5+wivRFF+UJ2nMSa+NG1APEi3W63iXc5zPuwddyqT2UgYTmwG3fzse25qc6QtZM
> Heu31opWcCUMqBYYushL3yD18bYfUiav1boF0DYewOkpBTgQkzZl1WyDBvSd5pVz
> tPle+v2dj8IbqHgT2ALOuvCOiH0troqb6b/SmV7lNapVgMCYoDhSFnPkhJ2k000g
> ni+h8bQ5LNSq5eUI2hpafQoi5bQc3yzUCqz4IJ+2ZCNvjiHuL466XkXeel6BzKPV
> 6w19aWbG8vvhJYQFmx+6PrysSNj4lhIegWp6e9os3/2gg07+TlIjR98erlGe/Llq
> uHTNbIsQaUf53uA7pGRIKp/DKmdKpUk5+BO1q1jFjbHwvcIhkUs4asGJV7e026CY
> eGiiZbFL
> =U8fE
> -END PGP SIGNATURE-
>
>

[gentoo-user] Openrc - where to register services for discovery

[Damo Brisbane]

I'd like to add hooks into an openrc startup script for sidecar

 type functionality, ie service discovery registration, but not exactly
sure the best way to do it. The problem seems to happen often enough that
i'd welcome some feedback on it. Preferably openrc, but s6 experience
appreciated. For example;

To add service discovery to the starting of some init.d service, eg lets
say a docker container, the container starts every time as a result of
running */etc/init.d/docker start*, and as a consequence of being created
with:

--restart=always

With above flag, the container will automatically start as part of the
standard docker init script, "/etc/init.d/docker start". But in my case,
the container does not natively register itself with consul (or could be
any other service discovery system). I know that I can run another
container to do the job of registering the container into the service
discovery system, but interested in any alternative *within the init
system*, ie using openrc script?

Might it as a *post-hook*, or as an extra file in some *conf.d* place? I
could hack together something, ie using a piece of code like "curl
.../register/myservice", but prefer to hear other peoples
experience/knowledge on how/where this may be done.
Cheers

[gentoo-user] ansible daemon

[Damo Brisbane]

Hi,

I am wanting to have continuously running ansible daemon to push out
desired state to some servers. I do not see such functionally covered
within readme (https://wiki.gentoo.org/wiki/Ansible). Am I correct to
assume that if I want to run ansible as a daemon, I will have to set up [if
I want] *ansible user*, init.d/ansible rc script?

Also note I haven't used Ansible in production - I am assuming that running
as a daemon is best for this scenario.

Thank you
Damon

Re: [gentoo-user] distributed emerge

[Damo Brisbane]

Thanks, digesting it!

On Tue, Sep 26, 2017 at 12:59 AM, Andrés Becerra Sandoval <
andres.bece...@gmail.com> wrote:

>
>
> 2017-09-25 6:35 GMT-05:00 Damo Brisbane <dhatche...@gmail.com>:
>
>> hi,
>>
>> Can someone point where I might go for parallel @world build, it is
>> really for my own curiositynat this time. Currently I stage binaries for
>> multiple machines on a single nfs share, but the assumption is to use
>> instead some distributed filesystem. So I think I just need a recipie,
>> pointers or ideas on how to distribute emerge on an @world set? I am
>> thinking granular first, ie per package rather than eg distributed gcc
>> within a single package.
>>
>> thank you
>>
>
>
> ​Hello,
>
> I think distcc might be what you look for the merging part:
> ​https://wiki.gentoo.org/wiki/Distcc
>
> --
>   Andrés Becerra Sandoval
>
>

[gentoo-user] distributed emerge

[Damo Brisbane]

hi,

Can someone point where I might go for parallel @world build, it is really
for my own curiositynat this time. Currently I stage binaries for multiple
machines on a single nfs share, but the assumption is to use instead some
distributed filesystem. So I think I just need a recipie, pointers or ideas
on how to distribute emerge on an @world set? I am thinking granular first,
ie per package rather than eg distributed gcc within a single package.

thank you

Re: [gentoo-user] electron and sslv3

[Damo Brisbane]

FYI this info and use flags worked for me to get a clean *electron* build
(with also getting eg *nodejs *dependency). I think also works for
chromium. I doubt "static-libs" is making any difference:

*/etc/portage>* emerge --info electron

dev-libs/openssl-1.0.2l::gentoo was built with the following:
USE="asm sslv2 sslv3 static-libs tls-heartbeat zlib -bindist -gmp -kerberos
-rfc3779 -sctp -test -vanilla"

*/etc/portage>* emerge --info electron

dev-libs/openssl-1.0.2l::gentoo was built with the following:
USE="asm sslv2 sslv3 static-libs tls-heartbeat zlib -bindist -gmp -kerberos
-rfc3779 -sctp -test -vanilla"

*/etc/portage>* egrep -r "(ssl|electron|nodejs)" pack*

package.accept_keywords:>=dev-libs/openssl-1.0.2l ~amd64
package.accept_keywords:=dev-util/electron-1.3.13-r1 ~amd64

package.mask/mask:=dev-libs/openssl-1.0.1
package.mask/mask:=dev-libs/openssl-1.0.2g
package.mask/mask:=dev-libs/openssl-1.1.0f
package.use/use:>=dev-libs/openssl-1.0.2l ssl sslv2 sslv3 static-libs


On Mon, Sep 4, 2017 at 4:23 PM, Damo Brisbane <dhatche...@gmail.com> wrote:

> Emerge -pv openssl:
>
> [ebuild   R] dev-libs/openssl-1.0.2l::gentoo  USE="asm sslv3
> tls-heartbeat zlib -bindist -gmp -kerberos -rfc3779 -sctp -sslv2
> -static-libs {-test} -vanilla"...
>
> I figured ssl better off without it; I think the issue with this package
> is it builds it's own version of chromium as part of the emerge, and I
> think this is where the ssl dependency comes in. Right though, I think
> package maintainer is where I need to head to next.
>
> Thanks
>
> On Sat, Sep 2, 2017 at 11:40 AM, Adam Carter <adamcart...@gmail.com>
> wrote:
>
>> On Sat, Sep 2, 2017 at 6:26 AM, Damo Brisbane <dhatche...@gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I am having troubles installing dev-util/electron, related to linking in
>>> "ssl3" in the final step of the ebuild, from build log:
>>>
>>> /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
>>> cannot find -lssl3
>>>
>>>
>>> FYI on ssl, I only want a "working/current" ssl and/or tls installation
>>> and I don't care for the details around the installation other than I would
>>> like - as much as possible - "ssl" to be future proof and compatible with
>>> current and new installs; in this case I just want electron, and I can't
>>> install the package because of this linking error. I can successfully build
>>> by hacking the final link step and simply remove the reference to "-lssl",
>>> below:
>>>
>>>
>>> > cd $PORTAGE_TMPDIR/dev-util/electron-1.3.13-r1/work/chromium-52
>>> .0.2743.82/out/R
>>> > x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--a 
>>> > obj/atom/app/electron.atom_main.o  obj/libelectron_lib.a
>>> o... lib/libnode.so lib/libv8.so -lz -lhttp_parser -lssl -lcrypto -
>>>
>>>
>>> and compiles fine.
>>>
>>> There are no "ssl" use flags on electron?:
>>>
>>
>> My first guess would be that your openssl is not compiled with sslv3. The
>> ebuild for electron only asks for >=dev-libs/openssl-1.0.2g:0=[-bindist]
>> not openssl[sslv3]. If that's the problem then there's a bug in electrons
>> ebuild.
>>
>> What does emerge -pv openssl show for use flags?
>>
>> However, ssl is pretty much deprecated these days due to security issues,
>> so unless you have a need to support something that cant do TLS, you're
>> better off leaving it out. Another issue may be that -lssl may be a loose
>> term for SSL+TLS...
>>
>
>

Re: [gentoo-user] electron and sslv3

[Damo Brisbane]

Emerge -pv openssl:

[ebuild   R] dev-libs/openssl-1.0.2l::gentoo  USE="asm sslv3
tls-heartbeat zlib -bindist -gmp -kerberos -rfc3779 -sctp -sslv2
-static-libs {-test} -vanilla"...

I figured ssl better off without it; I think the issue with this package is
it builds it's own version of chromium as part of the emerge, and I think
this is where the ssl dependency comes in. Right though, I think package
maintainer is where I need to head to next.

Thanks

On Sat, Sep 2, 2017 at 11:40 AM, Adam Carter <adamcart...@gmail.com> wrote:

> On Sat, Sep 2, 2017 at 6:26 AM, Damo Brisbane <dhatche...@gmail.com>
> wrote:
>
>> Hello,
>>
>> I am having troubles installing dev-util/electron, related to linking in
>> "ssl3" in the final step of the ebuild, from build log:
>>
>> /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
>> cannot find -lssl3
>>
>>
>> FYI on ssl, I only want a "working/current" ssl and/or tls installation
>> and I don't care for the details around the installation other than I would
>> like - as much as possible - "ssl" to be future proof and compatible with
>> current and new installs; in this case I just want electron, and I can't
>> install the package because of this linking error. I can successfully build
>> by hacking the final link step and simply remove the reference to "-lssl",
>> below:
>>
>>
>> > cd $PORTAGE_TMPDIR/dev-util/electron-1.3.13-r1/work/chromium-
>> 52.0.2743.82/out/R
>> > x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--a 
>> > obj/atom/app/electron.atom_main.o  obj/libelectron_lib.a
>> o... lib/libnode.so lib/libv8.so -lz -lhttp_parser -lssl -lcrypto -
>>
>>
>> and compiles fine.
>>
>> There are no "ssl" use flags on electron?:
>>
>
> My first guess would be that your openssl is not compiled with sslv3. The
> ebuild for electron only asks for >=dev-libs/openssl-1.0.2g:0=[-bindist]
> not openssl[sslv3]. If that's the problem then there's a bug in electrons
> ebuild.
>
> What does emerge -pv openssl show for use flags?
>
> However, ssl is pretty much deprecated these days due to security issues,
> so unless you have a need to support something that cant do TLS, you're
> better off leaving it out. Another issue may be that -lssl may be a loose
> term for SSL+TLS...
>

[gentoo-user] electron and sslv3

[Damo Brisbane]

Hello,

I am having troubles installing dev-util/electron, related to linking in
"ssl3" in the final step of the ebuild, from build log:

/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
cannot find -lssl3


FYI on ssl, I only want a "working/current" ssl and/or tls installation and
I don't care for the details around the installation other than I would
like - as much as possible - "ssl" to be future proof and compatible with
current and new installs; in this case I just want electron, and I can't
install the package because of this linking error. I can successfully build
by hacking the final link step and simply remove the reference to "-lssl",
below:


> cd
$PORTAGE_TMPDIR/dev-util/electron-1.3.13-r1/work/chromium-52.0.2743.82/out/R
> x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--a
obj/atom/app/electron.atom_main.o  obj/libelectron_lib.a
o... lib/libnode.so lib/libv8.so -lz -lhttp_parser -lssl -lcrypto -


and compiles fine.

There are no "ssl" use flags on electron?:

my build:

[ebuild  N~] dev-util/electron-1.3.13-r1  USE="proprietary-codecs
system-ffmpeg tcmalloc -cups -custom-cflags -gnome -gnome-keyring -hidpi
-kerberos -lto (-neon) -pic -pulseaudio (-selinux) {-test}" L10N="en-GB"


from https://packages.gentoo.org/packages/dev-util/electron:

LOCAL USE FLAGS


   - hidpi 
   - lto 
   - pic 
   - proprietary-codecs
   
   - system-ffmpeg 
   - tcmalloc 



FYI, this is state of ssl on my machine:

*  dev-libs/openssl
  Latest version available: 1.0.2l
  Latest version installed: 1.0.2l

*  dev-perl/IO-Socket-SSL
  Latest version available: 2.24.0
  Latest version installed: 2.24.0

*  dev-perl/Net-SMTP-SSL
  Latest version available: 1.30.0
  Latest version installed: 1.30.0

*  dev-perl/Net-SSLeay
  Latest version available: 1.810.0
  Latest version installed: 1.810.0

*  net-libs/gnutls
  Latest version available: 3.5.13
  Latest version installed: 3.5.13


Any help on how to successfully compile and install electron would be much
appreciated.