Slackpkg inside lxc container

Totoro-kun · 10-21-2018, 04:47 AM

Hello,

I am running Slackware64-14.2 host and using Slackware64-14.2 LXC containers on it. I am having an interesting problem which is hard for me to troubleshoot.

Basically, if I want to install software inside container by using slackpkg, the ncurses dialog window usually (not always) does not respond to keyboard. I can only kill it with CTRL+C.

There is absolutely no 3rd party software packages neither on host or containers. I am using en_US.UTF-8 locale everywhere and I cannot seem to spot any real correlation in case when or how it works or not work.

It does not matter if I run command from host:
# lxc-attach -n container slackpkg install samba

Or from containers shell:
# lxc-attach -n container
# slackpkg install samba

If I close my terminal application and open several times, then it starts to work properly for a while. Or so it seems.

Containers are being created most standard way:
MIRROR=http://mirrors.atviras.lt/slackware release=14.2 lxc-create -n containername -t slackware

Just wondering which end to explore. Can it be something wrong with my bash environment on client? Or Server? Or Container?

But my .bashrc is pretty basic:

Code:

export PS1="[\[\033[1;34m\w\033[0m]\n[\h \u]$ "
export HISTSIZE="" # Unlimited history
export HISTFILESIZE="" # Unlimited history
export HISTCONTROL=ignoredups #don't put duplicate lines in the history.

Maybe some missing package on the container? But it looks like I have only one dependency unmet, which is gd.so for memusagestat

Code:

# ./missing-deps /usr/bin/
The following file in /usr/bin/ depend on a lib and will need to be rebuilt:
-------
memusagestat
	libgd.so.3 => not found

I've checked /bin /lib64 /sbin /usr/bin /usr/lib64 /usr/sbin/

Maybe someone else have encountered a similar problem? Or could offer some clue please?

P.S.
For time being I am using slackpkg in batch mode, for some cases it's great functionality, but can be dangerous:

Code:

slackpkg -batch=on -default_answer=y install samba

crts · 10-21-2018, 04:56 AM

I also had trouble with slackpkg in a container, not exactly as you describe them though. In my case I could avoid those by using 'lxc-console' to attach to the container. If I use 'lxc-attach' I do not get a proper environment, e.g., $HOME is not set and thus a simple 'cd' leads nowhere instead of switching to my home folder. I also think that '.bashrc' will not get sourced but I am not sure about it. Since I solved it with 'lxc-console' I did not investigate any further. Try it and let me know if the problems persist.

Totoro-kun · 10-21-2018, 05:02 AM

Thank you!

lxc-console approach, does work consistently. But is a bit less convenient than lxc-attach. So there must be something with the way lxc-attach handles profile then.

crts · 10-21-2018, 05:11 AM

It *might* be enough if you just source your '.bashrc' manually, i.e.,

Code:

# source /root/.bashrc

I have not tried it myself since I do not mind the extra step of logging in via 'lxc-console'.

Totoro-kun · 10-21-2018, 05:30 AM

Just tried to use lxc-attach and source /etc/profile by doing . /etc/profile and same thing with .bash_profile and .bashrc, but neither step helped. Slackpkg dialog is still unresponsive.

crts · 10-21-2018, 05:38 AM

If it is a mere convenience issue you can also login with 'ssh', in my case this works, too. You will have, however, to configure 'ssh' to login with public/private key authentication once, if you want to avoid typing a password in the future.

Totoro-kun · 10-21-2018, 10:38 AM

Yes, access via ssh would be slightly more convenient than typing passwords each time indeed. And I do run ssh on some containers already (for file sharing purposes mainly). However, it is still much easier to manage numerous containers by using lxc-attach than by adding containers to already lengthy ssh config.

Either way it is still very helpful to know that slackpkg can be used normally via lxc-console or ssh session. It is now possible to investigate further.

mralk3 · 10-21-2018, 10:42 AM

The issue has something to do with the environment settings (env). I tried to get it working with something like:

Code:

lxc-attach --keep-env -n container

This fixes the garbled text but the dialog window launched by slackpkg appears to be unresponsive. I am interested in a solution as well. A web search did not yield anything useful, at least for me. It might be more effective to look at what changes other distributions have made to get lxc-attach working with a dialog/ncurses interface.

mralk3 · 10-21-2018, 10:49 AM

For the time being, I set DIALOG=off in /etc/slackpkg/slackpkg.conf. This provides a text interface to slackpkg.

Totoro-kun · 10-21-2018, 11:02 AM

Thanks!

Setting DIALOG=off in /etc/slackpkg/slackpkg.conf is actually quite cool workaround! In my case, it seems to serve even nicer than dialog.

Just tried lxc-attach --keep-env thing, but it does not seem to help. So possibly other ncurses/dialog applications could still have issue.

mralk3 · 10-21-2018, 11:09 AM

Quote:

Originally Posted by Totoro-kun

Thanks!

Setting DIALOG=off in /etc/slackpkg/slackpkg.conf is actually quite cool workaround! In my case, it seems even nicer than dialog.

DEFAULT_ANSWER=y
BATCH=on

Could also be useful depending on what your container is for. The only downside with DIALOG=off is that if you do something like:

Code:

slackpkg reinstall python

You get every package with the word "python" in the results. It doesn't look like regex is viable with slackpkg, so you will likely want to do a:

Code:

slackpkg search python

..package list..

slackpkg reinstall python-2.7.15

The nice part of the dialog window is you can select/deselect packages. Hopefully your use case doesn't need this feature.

crts · 10-21-2018, 12:08 PM

Just a heads-up about --keep-env from the manpage:

Code:

       --keep-env
              Keep the current environment for attached programs. This is  the
              current  default behaviour (as of version 0.9), but is is likely
              to change in the future, since this may leak undesirable  infor‐
              mation  into the container. If you rely on the environment being
              available for the attached program, please use this option to be
              future-proof. In addition to current environment variables, con‐
              tainer=lxc will be set.

crts · 06-05-2019, 02:19 AM

I do not know if this is still an issue for you OP but I recently found a possible solution. After attaching with 'lxc-attach' just run

Code:

# sudo -i

This will log you in as root again but this time with a "proper" environment. I also tried

Code:

# su -

but that did not work. Let me know if this fixes the issue for you, OP.

Totoro-kun · 06-09-2019, 01:40 PM

Hi,

It's less of an issue now, that I've switched to using slackpkg without dialog interface. It's more convenient to semi-automate this process by the use of scrips

Anyhow, thank you for suggestions. I did try sudo -i method, but it did not had any effect unfortunately.

chris.willing · 06-10-2019, 02:15 AM

Quote:

Originally Posted by Totoro-kun

Hi,

It's less of an issue now, that I've switched to using slackpkg without dialog interface. It's more convenient to semi-automate this process by the use of scrips

Anyhow, thank you for suggestions. I did try sudo -i method, but it did not had any effect unfortunately.

To spot the difference, lxc-attach to your container and (before doing anything else) run the command 'env'; note the details. Now do the 'sudo -i' thing and run 'env' again. Spot the difference? I'll bet there's enough there now to run slackpkg with the dialog interface - it works for me.

Thanks crts for that trick (I mean technique). Previously I used to source a handmade script to set up a sufficient environment but the 'sudo -i' technique is much better.

chris