Re: Trouble with ansible and apt. Is this a known problem?
David Wright writes: On Fri 25 Nov 2022 at 15:13:48 (+0100), Nathanael Schweers wrote: > We need to know the versions of the (relevant) packages on > your system. Sorry, I have the ones currently in bullseye. I’m afraid I am not at said machine at the moment and won’t be for the weekend. I’ll post more next week. > BTW you started this thread with "I recently installed Debian > Bullseye > on my desktop machine, having previously used Debian sid." We > need to > know whether the last part of that sentence is of any > relevance, or > just an aside. That was just there to indicate that this works perfectly fine on sid. I have another machine (which I’m using at the moment), which runs sid without any of the problems I’ve described here. What worried me was that you might, on the desktop machine, have carried over configuration files in /home from the sid version to bullseye. Your mentioning since, that there are some files (I know not what) in ~/.local/bin/ make that a reasonable question to ask. I started writing a reply to this about how I checked and re-checked for any such files. I was about to check the output of `ansible-playbook --version`, both in `$HOME/.local/bin` and in `/usr/bin`. Then it hit me, that ansible is using more files than I anticipated. Removing these fixed my issue! Many many thousand thanks to you and everyone else who helped me with this! Kind regards, Nathanael
Re: Re: Trouble with ansible and apt. Is this a known problem?
> We also need to know what happened between the "I recently installed Debian" > statement and your "suddenly 2 days ago Ansible..." statement. I’m not quite sure I follow. I put that in my message to indicate that it was running fine on sid. It still is, in fact, on another machine. Between installing Debian Bullseye and encountering said problems ansible worked fine. While debugging this (but before I posted to this list) I realized that I had a pip installation in ~/.local/bin/. I have no idea where that came from. Updating the pip installation eventually fixed my issues, but removing it still causes the same problems. > The python runtime messages probably indicate a missing variable. But have > you determined that is the actual error? And from where it is missing? That python3-cryptography has the bug that this particular field is missing is known. I would have expected that to be in a version not in Bullseye. As I’ve mentioned in another answer I’ll take a look at the exact versions installed when I get back to the machine in question next week. Cheers, Nathanael
Re: Re: Trouble with ansible and apt. Is this a known problem?
> We need to know the versions of the (relevant) packages on your system. Sorry, I have the ones currently in bullseye. I’m afraid I am not at said machine at the moment and won’t be for the weekend. I’ll post more next week. > BTW you started this thread with "I recently installed Debian Bullseye > on my desktop machine, having previously used Debian sid." We need to > know whether the last part of that sentence is of any relevance, or > just an aside. That was just there to indicate that this works perfectly fine on sid. I have another machine (which I’m using at the moment), which runs sid without any of the problems I’ve described here. Cheers, Nathanael.
Re: Re: Trouble with ansible and apt. Is this a known problem?
> It doesn't look like this exact problem is known at > https://github.com/search?q=org%3Aansible+X509_V_FLAG_CB_ISSUER_CHECK+is%3Aissue&type=issues, > but there are a few suggestions among the matching bugs. > One suggestion appears to be that your python module "cryptography" is too > new for Ansible. You don't state how you installed Ansible, but you might > find installing it into a virtualenv is more reliable. I installed ansible from apt. I therefore wonder how the debian package for `python3-cryptography` can be too new for ansible, which is also installed via apt, not pip. I removed the pip installation from my user’s home directory and even re-installed all already installed python packages on my system, but I still have the same problem. Is this actually broken on debian at the moment? Kind regards, Nathanael
Trouble with ansible and apt. Is this a known problem?
Hello people, I recently installed Debian Bullseye on my desktop machine, having previously used Debian sid. So far it all went well. Yet two days ago, ansible suddenly reported the following message when attempting to use either the `apt` or `package` builtin. fatal: [schweers-pc]: FAILED! => changed=false module_stderr: |- Shared connection to schweers-pc closed. module_stdout: |2- Traceback (most recent call last): File "/home/schweers/.ansible/tmp/ansible-tmp-1669020286.4378655-35342-213285731346074/AnsiballZ_apt.py", line 102, in _ansiballz_main() File "/home/schweers/.ansible/tmp/ansible-tmp-1669020286.4378655-35342-213285731346074/AnsiballZ_apt.py", line 94, in _ansiballz_main invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS) File "/home/schweers/.ansible/tmp/ansible-tmp-1669020286.4378655-35342-213285731346074/AnsiballZ_apt.py", line 40, in invoke_module runpy.run_module(mod_name='ansible.modules.apt', init_globals=None, run_name='__main__', alter_sys=True) File "/usr/lib/python3.9/runpy.py", line 210, in run_module return _run_module_code(code, init_globals, run_name, mod_spec) File "/usr/lib/python3.9/runpy.py", line 97, in _run_module_code _run_code(code, mod_globals, init_globals, File "/usr/lib/python3.9/runpy.py", line 87, in _run_code exec(code, run_globals) File "/tmp/ansible_ansible.legacy.apt_payload_og4qifjt/ansible_ansible.legacy.apt_payload.zip/ansible/modules/apt.py", line 302, in File "", line 1007, in _find_and_load File "", line 986, in _find_and_load_unlocked File "", line 664, in _load_unlocked File "", line 627, in _load_backward_compatible File "", line 259, in load_module File "/tmp/ansible_ansible.legacy.apt_payload_og4qifjt/ansible_ansible.legacy.apt_payload.zip/ansible/module_utils/urls.py", line 115, in File "/usr/lib/python3/dist-packages/urllib3/contrib/pyopenssl.py", line 50, in import OpenSSL.SSL File "/usr/lib/python3/dist-packages/OpenSSL/__init__.py", line 8, in from OpenSSL import crypto, SSL File "/usr/lib/python3/dist-packages/OpenSSL/crypto.py", line 1556, in class X509StoreFlags(object): File "/usr/lib/python3/dist-packages/OpenSSL/crypto.py", line 1577, in X509StoreFlags CB_ISSUER_CHECK = _lib.X509_V_FLAG_CB_ISSUER_CHECK AttributeError: module 'lib' has no attribute 'X509_V_FLAG_CB_ISSUER_CHECK' msg: |- MODULE FAILURE See stdout/stderr for the exact error rc: 1 Note that it does not matter that the package in question is already installed. I have tried to reinstall `python3-urllibs`, `python3-apt` and `python3-openssl` yet to no avail. Is this a known problem? Kind regards, Nathanael
Re: Debian "Bookworm" Installation
David Christensen writes: > I use the d-i at the simplest level I can (e.g. text "Install" mode from the > main menu). From what I have observed, d-i detects if the host is using BIOS > or > UEFI, and chooses MBR or GPT partitioning accordingly. Assume the host > firmware > can operate as UEFI, I would use the CMOS Setup program to set the host > firmware > to UEFI and then boot d-i. It might be possible or even necessary to boot the USB-drive in UEFI mode. I have seen firmware interfaces which have this option when determining the boot order. I.e. just having the firmware be in UEFI mode might not be enough. Regards, Nathanael
Re: fluxbox partial installation (SOLUTION)
Haines Brown writes: > On Sat, Apr 02, 2022 at 02:52:59PM +0200, Nathanael Schweers wrote: >> That’s how most window managers are designed to work. I certainly do >> something similar with i3. > > Nathan I copied over the .fluxbox hierarchy. It turned out this can be > done, but lines left in ./fluxbox/start up would not allow X server to > start. Commenting them allowed fluxbox to load. I’m not that familiar with fluxbox, at least not anymore. Is it possible that your ~/.fluxbox/start tries to do things that won’t work on your current system? For instance start programs which are not present? In such a case I would guess that fluxbox terminates. But please note: I’m making educated guesses here, nothing more :-) Regards, Nathan
Re: fluxbox partial installation
Haines Brown writes: > After installing base system (without DE) I install xorg and then > fluxbox. > > Fluxbox gets installed, but no ~/.fluxbox directory shows up. I haven’t used fluxbox for many years, but I don’t use a DE either. For what it’s worth, I use i3, which also does not place a configuration in $HOME. I guess it would not be a good idea for a package to place a file in every $HOME directory which happens to exist at the time the package is installed. > > Another question: can the ~/.fluxbox directory hierarchy simply be > copied over from a working system? That’s how most window managers are designed to work. I certainly do something similar with i3. Regards, Nathan
Re: swap maxed out when plenty of RAM available
Adam Weremczuk writes: > The container was running like that for several months until this morning > when its core service (dhcp) started failing. Just a wild guess, but do you know what caused dhcp to fail? Was it too little memory? > > I logged in to investigate and noticed 100% of swap being used with maybe > 10-20% of RAM in use. If I recall correctly, Linux may choose to swap pages out in order to free up physical memory in order to use said memory for buffers and caches. This is a performance optimization. So if there are pages which have not been touched for a while, but I/O performance might benefit from a larger cache, this is actually good for performance. Regards, Nathanael
Re: system drive encryption question
Pascal Hambourg writes: > The version of GRUB included in Jessie at least can handle an encrypted > /boot. However the Debian installer does not handle this case correctly. > You must add the following line in /etc/default/grub in order for > grub-install to install the core image with crypto modules and for > update-grub to generate a proper grub.cfg : > > GRUB_ENABLE_CRYPTODISK=y > > (not =1 or =true as seen on some documentation) > > The procedure in the post you point to is flawed in Debian Jessie : if > you run update-grub or grub-mkconfig before adding the line in > /etc/default/grub, it won't add the required "cryptomount" commands to > open encrypted devices. Actually it is grub-mkconfig which is broken : > if the line is present, it adds an cryptomount command in every menu > entry, even when not needed (and generates boot-time errors). If the > line is missing, it adds insmod commands to load crypto modules when > needed but not the cryptomount commands. I never said that it works on debian. I just wanted to point out that it is not strictly necessary to have an unencrypted /boot partition.
Re: system drive encryption question
Rick Thomas writes: > I used to do this. It worked very well before Jessie came along. > > You need an un-encrypted /boot partition to hold the kernel and > initrd, of course… This is not true, although I also thought it to be the case. Grub2 can handle LUKS, so it is possible to encrypt the whole disk. I recently stumbled across a post where the procedure is explained using archlinux as an example. I’m not sure whether debian includes a version of Grub which can also do so, but in principle an unencrypted /boot partition is not needed. This is the post in question: http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-the-party/ Regards, Nathanael Schweers
Re: Almost all gpg2 operations hang after upgrade to stretch/testing
Nicolas George writes:
> Le septidi 17 germinal, an CCXXV, Nathanael Schweers a écrit :
>> connect(6, {sa_family=AF_UNIX,
>> sun_path="/run/user/1000/gnupg/S.gpg-agent"}, 34) = 0
>> read(6,
>>
>> It seems to me that strace shouldn’t just stop in the middle of an
>> argument list, but I might be wrong.
>
> It is perfectly normal. strace will print the contents of the buffer
> that has just been read, but for that, it must wait that the syscall
> finished.
>
> Thus, we know that the problem is the agent not responding at all to the
> client. stracing the agent may give more information.
Ah, thanks a lot for that tip! I went again and looked how the agent is
started, as it immediately respawned whenever I sent SIGTERM to it.
Turns out, I still had a systemd user service, which started the agent
using environment variables and the like. As soon as I had removed that
service and performed a reboot (I’m not sure what exactly would have to
be restarted), everything worked!
At any rate, you really saved my day, thank you so much!
>
>> 5307 pts/4S+ 0:00 grep --color=auto --exclude-dir=.bzr
>> --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg
>> --exclude-dir=.svn -i gpg
>
> As a side note, you might be interested to know "git grep"; it greps
> tracked files but not the repository, and even works when working out of
> tree.
Those seem to be the default arguments for grep or something. I use
oh-my-zsh, it may come from there. Also, I know about git grep, yet
hardly use it. Maybe I should ;)
Regards,
Nathanael Schweers
Re: Almost all gpg2 operations hang after upgrade to stretch/testing
When I run strace gpg2 -d notes.org.gpg strace stops output in mid
syscall(?)
[... cut ...]
open("/usr/share/locale/en_US/LC_MESSAGES/libgpg-error.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libgpg-error.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
getuid()= 1000
stat("/run/user/1000", {st_mode=S_IFDIR|0700, st_size=160, ...}) = 0
getuid()= 1000
stat("/run/user/1000/gnupg", {st_mode=S_IFDIR|0700, st_size=140, ...}) = 0
getuid()= 1000
stat("/run/user/1000/gnupg/S.gpg-agent", {st_mode=S_IFSOCK|0600,
st_size=0, ...}) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 6
stat("/run/user/1000/gnupg/S.gpg-agent", {st_mode=S_IFSOCK|0600,
st_size=0, ...}) = 0
connect(6, {sa_family=AF_UNIX,
sun_path="/run/user/1000/gnupg/S.gpg-agent"}, 34) = 0
read(6,
It seems to me that strace shouldn’t just stop in the middle of an
argument list, but I might be wrong.
I ran ps in a different terminal to see what gpg stuff is running:
$ ps ax | grep -i gpg
5230 pts/1S+ 0:00 strace gpg2 -d notes.org.gpg
5232 pts/1SL+0:00 gpg2 -d notes.org.gpg
5260 ?SLs0:00 /usr/bin/gpg-agent --daemon
--enable-ssh-support --use-standard-socket --write-env-file
/run/user/1000/gpg-agent.info
5307 pts/4S+ 0:00 grep --color=auto --exclude-dir=.bzr
--exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg
--exclude-dir=.svn -i gpg
Also the socket file seems fine:
$ ls -l /run/user/1000/gnupg/S.gpg-agent
srw--- 1 schweers schweers 0 Apr 6 08:54
/run/user/1000/gnupg/S.gpg-agent
On 04/06/2017 10:15 AM, Nicolas George wrote:
> Le septidi 17 germinal, an CCXXV, Nathanael Schweers a écrit :
>> For instance gpg2 -K --verbose prints "gpg: using pgp trust model", but
>> then just hangs. Trying to decrypt a file via gpg2 -d --verbose
>> simply outputs what my public key is (I think a fingerprint
>> is listed), and then also hangs.
>>
>> gpg2 -k on the other hand works.
> Is the GPG agent running correctly?
>
> You could try strace to see what exactly is blocking.
>
> Regards,
>
Almost all gpg2 operations hang after upgrade to stretch/testing
Hi fellow debian users, after upgrading a system running debian jessie/stable, I performed an upgrade to stretch/testing, which went fairly well for the most part. I had a few issues, but nothing I couldn’t handle. I have unresolved issues with gpg though. This is what happened so far: Most operations on gpg2 gave me a message that the old keys will be migrated. The problem is: this seemed to hang indefinitely, without consuming many resources. As I couldn’t find a solution, I copied my whole ~/.gnupg directory to a different machine, where the migration had been successful for other keys (created and used on debian jessie, then migrated to archlinux, gpg2 version 2.1.19). This worked, and I copied ~/.gnupg back again. The problem is: this didn’t resolve my issue. The migrated keys work fine on the archlinux machine where I performed the migration, yet practically all operations on my debian machine simply hang without much output as to what is supposed to happen or consuming resources. While writing this mail I realized that the slightly older version of gpg2 on stretch (2.1.18) may be an issue. Can this be the case? For instance gpg2 -K --verbose prints "gpg: using pgp trust model", but then just hangs. Trying to decrypt a file via gpg2 -d --verbose simply outputs what my public key is (I think a fingerprint is listed), and then also hangs. gpg2 -k on the other hand works. As I have a backup of my complete home directory from before the system upgrade, I still have access to ~/.gnupg as it was before the upgrade, should that be necessary. Does anyone have an idea what the problem might be? Best regards, Nathanael Schweers
