Bug#1016167: 389-ds-base: dscreate does not work due to race condition when starting and connecting to LDAP server instance
Package: 389-ds-base
Version: 1.4.4.11-2
Severity: important
X-Debbugs-Cc: mgronczew...@efigence.com
I've tried to create the new instance via dscreate from-file (tried interactive
version with default config with no changes too) and it crashes after starting
server and questionnaire, because it tries to connect to server that is
*started* but not yet listening on the socket:
Enter the Directory Manager password:
Confirm the Directory Manager Password:
Enter the database suffix (or enter "none" to skip)
[dc=ldap,dc=example,dc=com]: none
Do you want to start the instance after the installation? [yes]: yes
Are you ready to install? [no]: yes
Starting installation...
Error: Can't contact LDAP server - 111 - Connection refused
after turning the verbose mode:
...
DEBUG: systemd status -> True
DEBUG: systemd status -> True
DEBUG: open(): Connecting to uri ldapi://%2Fvar%2Frun%2Fslapd-main.socket
DEBUG: Using dirsrv ca certificate /etc/dirsrv/slapd-main
DEBUG: Using external ca certificate /etc/dirsrv/slapd-main
DEBUG: Using external ca certificate /etc/dirsrv/slapd-main
DEBUG: Using /etc/openldap/ldap.conf certificate policy
DEBUG: ldap.OPT_X_TLS_REQUIRE_CERT = 2
DEBUG: open(): Using root autobind ...
DEBUG: {'desc': "Can't contact LDAP server", 'errno': 111, 'info':
'Connection refused'}
Traceback (most recent call last):
File "/sbin/dscreate", line 80, in
result = args.func(inst, log, args)
File "/usr/lib/python3/dist-packages/lib389/cli_ctl/instance.py", line
68, in instance_create
if sd.create_from_inf(args.file):
File "/usr/lib/python3/dist-packages/lib389/instance/setup.py", line 538,
in create_from_inf
self.create_from_args(general, slapd, backends, self.extra)
...
Currently I've applied an ugly fix to my system that appears to solve the
problem:
--- /tmp/__init__.py2022-07-28 13:10:08.806516127 +0200
+++ /usr/lib/python3/dist-packages/lib389/__init__.py 2022-07-28
13:10:20.274329837 +0200
@@ -934,6 +934,7 @@
uri = self.toLDAPURL()
self.log.debug('open(): Connecting to uri %s', uri)
+time.sleep(10)
if hasattr(ldap, 'PYLDAP_VERSION') and MAJOR >= 3:
super(DirSrv, self).__init__(uri, bytes_mode=False,
trace_level=TRACE_LEVEL)
else:
and confirms my suspicion script tries to connect to the server that isn't up
yet (system service dirmgr@main.service is up and responding after installer
fails)
I've checked and both earlier(buster) and newer(bookworm) versions of package
appear to be working fine
-- System Information:
Debian Release: 11.4
APT prefers bullseye-security
APT policy: (500, 'bullseye-security')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages 389-ds-base depends on:
ii 389-ds-base-libs 1.4.4.11-2
ii acl 2.2.53-10
ii adduser 3.118
ii debconf [debconf-2.0]1.5.77
ii ldap-utils 2.4.57+dfsg-3+deb11u1
ii libc62.31-13+deb11u3
ii libcrypt11:4.4.18-4
ii libdb5.3 5.3.28+dfsg1-0.8
ii libicu67 67.1-7
ii libldap-2.4-22.4.57+dfsg-3+deb11u1
ii libmozilla-ldap-perl 1.5.3-3+b2
ii libnetaddr-ip-perl 4.079+dfsg-1+b5
ii libnspr4 2:4.29-1
ii libnss3 2:3.61-1+deb11u2
ii libpam0g 1.4.0-9+deb11u1
ii libsasl2-2 2.1.27+dfsg-2.1+deb11u1
ii libsasl2-modules-gssapi-mit 2.1.27+dfsg-2.1+deb11u1
ii libsnmp405.9+dfsg-3+b1
ii libsocket-getaddrinfo-perl 0.22-3
ii libsystemd0 247.3-7
ii perl 5.32.1-4+deb11u2
ii python3 3.9.2-3
ii python3-lib389 1.4.4.11-2
ii python3-selinux 3.1-3
ii python3-semanage 3.1-1+b2
ii python3-sepolicy 3.1-1
ii systemd 247.3-7
389-ds-base recommends no packages.
389-ds-base suggests no packages.
-- no debconf information
--
Mariusz Gronczewski, Administrator
Efigence S. A.
ul. Wołoska 9a, 02-583 Warszawa
T: [+48] 22 380 13 13
NOC: [+48] 22 380 10 20
E: ad...@efigence.com
Bug#981434: initramfs-tools: boot delayed by 30sec. due to /scripts/local-block loop
Package: initramfs-tools Version: 0.139 Severity: normal for more detail: #860533, as that one was closed without veryfing whether anything was fixed. still happens, in my case when GRUB had set resume=/dev/sda6 due to other bug the bug appeared, removing that from kernel cmdline stopped bug from triggering I also had set initramfs-tools/conf.d/resume: RESUME=none as I don't want resume in the first place -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64
Bug#981433: grub-efi-amd64: Grub keeps adding resume= after package update, triggering other bugs in the process
Package: grub-efi-amd64 Version: 2.04-12 Severity: normal after update, *again*, GRUB has re-added resume=/dev/sda6 diff --git a/default/grub b/default/grub index 7f80c69..911da28 100644 --- a/default/grub +++ b/default/grub @@ -35,3 +35,5 @@ GRUB_CMDLINE_LINUX_DEFAULT="cgroup_enable=memory kvm-intel.nested=1 net.ifnames= # Uncomment to get a beep at grub start #GRUB_INIT_TUNE="480 440 1" + +GRUB_CMDLINE_LINUX="resume=/dev/sda6 net.ifnames=0 cgroup_enable=memory swapaccount=1" Aside from the fact that I do not WANT to use resume and I disabled it via initramfs-tools/conf.d/resume: RESUME=none (or is it wrong way?) it triggers bug #860533 causing extra 30s of boot time -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64
Bug#720096: logrotate rsyslog bug
Hi, I believe that has to do with this bug:https://github.com/rsyslog/rsyslog/issues/3952 currently script used to rotate fails: invoke-rc.d rsyslog rotate Closing open files: rsyslogd failed! I also believe it is related to bug #831764 Currently removing -iNONE "fixes" it, altho I'm not sure whether that's a proper solution. We had the case where it caused rsyslog to run out of open files because rotate was never called and due to config (it's a log aggregator from many devices written) eventually it just has a ton of unclosed files open and stops getting new connections, so it is a pretty severe problem. -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64
Bug#932939: Reproduced bug 932939
Hi, We've got similar issue, altho setup is VM + virt-install + static IP/DNS/Route config What's different is that it does not always happen, re-trying few times usually finally gets it to work. In every case the device (virtio network adapter) is detected and working from installer's shell. As with other examples, setting a single console makes it reliable -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64
Bug#920345: [Pkg-freeradius-maintainers] Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit
Now that I looked, while current 3.x stable still uses forking, they have added support for Type=notify in current development ( https://github.com/FreeRADIUS/freeradius-server/blob/master/debian/freeradius.service ) of daemon itself so that should solve it. On Fri, 25 Jan 2019 at 14:31, Mariusz Gronczewski wrote: > > Okay, I will just poke the upstream about it, seems that CentOS/RHEL > package have exactly same problem so no point changing it just for > Debian. > > > On Thu, 24 Jan 2019 at 18:27, Michael Stapelberg > wrote: > > > > Ah, why didn’t you open with that suggestion? :) > > > > https://manpages.debian.org/stretch/systemd/systemd.service.5.en.html#OPTIONS > > outlines that switching to Type=simple (which is the consequence of your > > -f suggestion) means we won’t have start-up failure propagation anymore, > > and reverse-dependencies of freeradius will not be able to reliably > > sequence themselves. > > > > Now, I’m not sure whether these downsides are actually relevant in > > practice, as I don’t know much about the larger freeradius ecosystem. Maybe > > there are no communication channels, and no reverse dependencies of note? > > I’m not sure. > > > > If you could confirm with upstream that they are blessing use of -f and > > Type=simple as the default in Debian, I can make the change. > > > > Thanks, > > > > On Thu, Jan 24, 2019 at 4:49 PM Mariusz Gronczewski > > wrote: > >> > >> Well, there is, adding -f option by default means it will always run > >> in foreground, regardless of whether -X is used or not > >> > >> On Thu, 24 Jan 2019 at 15:58, Michael Stapelberg > >> wrote: > >> > > >> > The -X option is special in that it changes the way freeradius starts up. > >> > > >> > It’s expected that if your actions break the contract with the init > >> > system (in this case by specifying -X), you’re responsible to rectify > >> > that. > >> > > >> > If there was a simple way to make the package work in any/all cases, > >> > it’d be up for it, but I’m not aware of one. Hence my question for what > >> > your suggestion is — I just don’t see a way out of this situation. > >> > > >> > My personal recommendation is to not use /etc/default, but rather > >> > systemctl edit to do any overrides, but that’s not Debian’s official > >> > line. > >> > > >> > On Thu, Jan 24, 2019 at 3:37 PM Mariusz Gronczewski > >> > wrote: > >> >> > >> >> In our case it was enough to add dropin changing execstart to include > >> >> -f and type to simple: > >> >> > >> >> ExecStart=/usr/sbin/freeradius -f $FREERADIUS_OPTIONS > >> >> Type=simple > >> >> > >> >> What do you mean by "it is expected" ? Currently enabling debug (by > >> >> setting FREERADIUS_OPTIONS="-X") cause it to enter restart loop, > >> >> surely that isn't an expected behaviour ? > >> >> > >> >> On Thu, 24 Jan 2019 at 13:52, Michael Stapelberg > >> >> wrote: > >> >> > > >> >> > Yes, this is expected. What change are you suggesting? > >> >> > > >> >> > On Thu, Jan 24, 2019 at 1:45 PM Mariusz Gronczewski > >> >> > wrote: > >> >> >> > >> >> >> Package: freeradius > >> >> >> Version: 3.0.12+dfsg-5+deb9u1 > >> >> >> Severity: normal > >> >> >> > >> >> >> Currently the type of systemd service is forking. > >> >> >> > >> >> >> Adding debug to cmdline causes freeradius to run in foreground (and > >> >> >> dump debug > >> >> >> to stdout), which means systemd timeouts on starting service because > >> >> >> it assumes > >> >> >> it will fork. > >> >> >> > >> >> >> Changing type to simple, and adding -f (run in foreground) option in > >> >> >> unit file > >> >> >> fixes that > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> Mariusz Gronczewski (XANi) > >> >> >> GnuPG: 0xEA8ACE64 > >> >> >> > >> >> >> ___ > >> >> >> Pkg-freeradius-maintainers mailing list > >> >> >> pkg-freeradius-maintain...@alioth-lists.debian.net > >> >> >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Best regards, > >> >> > Michael > >> >> > >> >> > >> >> > >> >> -- > >> >> Mariusz Gronczewski (XANi) > >> >> GnuPG: 0xEA8ACE64 > >> > > >> > > >> > > >> > -- > >> > Best regards, > >> > Michael > >> > >> > >> > >> -- > >> Mariusz Gronczewski (XANi) > >> GnuPG: 0xEA8ACE64 > > > > > > > > -- > > Best regards, > > Michael > > > > -- > Mariusz Gronczewski (XANi) > GnuPG: 0xEA8ACE64 -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64
Bug#920345: [Pkg-freeradius-maintainers] Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit
Okay, I will just poke the upstream about it, seems that CentOS/RHEL package have exactly same problem so no point changing it just for Debian. On Thu, 24 Jan 2019 at 18:27, Michael Stapelberg wrote: > > Ah, why didn’t you open with that suggestion? :) > > https://manpages.debian.org/stretch/systemd/systemd.service.5.en.html#OPTIONS > outlines that switching to Type=simple (which is the consequence of your -f > suggestion) means we won’t have start-up failure propagation anymore, and > reverse-dependencies of freeradius will not be able to reliably sequence > themselves. > > Now, I’m not sure whether these downsides are actually relevant in practice, > as I don’t know much about the larger freeradius ecosystem. Maybe there are > no communication channels, and no reverse dependencies of note? I’m not sure. > > If you could confirm with upstream that they are blessing use of -f and > Type=simple as the default in Debian, I can make the change. > > Thanks, > > On Thu, Jan 24, 2019 at 4:49 PM Mariusz Gronczewski wrote: >> >> Well, there is, adding -f option by default means it will always run >> in foreground, regardless of whether -X is used or not >> >> On Thu, 24 Jan 2019 at 15:58, Michael Stapelberg >> wrote: >> > >> > The -X option is special in that it changes the way freeradius starts up. >> > >> > It’s expected that if your actions break the contract with the init system >> > (in this case by specifying -X), you’re responsible to rectify that. >> > >> > If there was a simple way to make the package work in any/all cases, it’d >> > be up for it, but I’m not aware of one. Hence my question for what your >> > suggestion is — I just don’t see a way out of this situation. >> > >> > My personal recommendation is to not use /etc/default, but rather >> > systemctl edit to do any overrides, but that’s not Debian’s official line. >> > >> > On Thu, Jan 24, 2019 at 3:37 PM Mariusz Gronczewski >> > wrote: >> >> >> >> In our case it was enough to add dropin changing execstart to include >> >> -f and type to simple: >> >> >> >> ExecStart=/usr/sbin/freeradius -f $FREERADIUS_OPTIONS >> >> Type=simple >> >> >> >> What do you mean by "it is expected" ? Currently enabling debug (by >> >> setting FREERADIUS_OPTIONS="-X") cause it to enter restart loop, >> >> surely that isn't an expected behaviour ? >> >> >> >> On Thu, 24 Jan 2019 at 13:52, Michael Stapelberg >> >> wrote: >> >> > >> >> > Yes, this is expected. What change are you suggesting? >> >> > >> >> > On Thu, Jan 24, 2019 at 1:45 PM Mariusz Gronczewski >> >> > wrote: >> >> >> >> >> >> Package: freeradius >> >> >> Version: 3.0.12+dfsg-5+deb9u1 >> >> >> Severity: normal >> >> >> >> >> >> Currently the type of systemd service is forking. >> >> >> >> >> >> Adding debug to cmdline causes freeradius to run in foreground (and >> >> >> dump debug >> >> >> to stdout), which means systemd timeouts on starting service because >> >> >> it assumes >> >> >> it will fork. >> >> >> >> >> >> Changing type to simple, and adding -f (run in foreground) option in >> >> >> unit file >> >> >> fixes that >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Mariusz Gronczewski (XANi) >> >> >> GnuPG: 0xEA8ACE64 >> >> >> >> >> >> ___ >> >> >> Pkg-freeradius-maintainers mailing list >> >> >> pkg-freeradius-maintain...@alioth-lists.debian.net >> >> >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers >> >> > >> >> > >> >> > >> >> > -- >> >> > Best regards, >> >> > Michael >> >> >> >> >> >> >> >> -- >> >> Mariusz Gronczewski (XANi) >> >> GnuPG: 0xEA8ACE64 >> > >> > >> > >> > -- >> > Best regards, >> > Michael >> >> >> >> -- >> Mariusz Gronczewski (XANi) >> GnuPG: 0xEA8ACE64 > > > > -- > Best regards, > Michael -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64
Bug#920345: [Pkg-freeradius-maintainers] Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit
Well, there is, adding -f option by default means it will always run in foreground, regardless of whether -X is used or not On Thu, 24 Jan 2019 at 15:58, Michael Stapelberg wrote: > > The -X option is special in that it changes the way freeradius starts up. > > It’s expected that if your actions break the contract with the init system > (in this case by specifying -X), you’re responsible to rectify that. > > If there was a simple way to make the package work in any/all cases, it’d be > up for it, but I’m not aware of one. Hence my question for what your > suggestion is — I just don’t see a way out of this situation. > > My personal recommendation is to not use /etc/default, but rather systemctl > edit to do any overrides, but that’s not Debian’s official line. > > On Thu, Jan 24, 2019 at 3:37 PM Mariusz Gronczewski wrote: >> >> In our case it was enough to add dropin changing execstart to include >> -f and type to simple: >> >> ExecStart=/usr/sbin/freeradius -f $FREERADIUS_OPTIONS >> Type=simple >> >> What do you mean by "it is expected" ? Currently enabling debug (by >> setting FREERADIUS_OPTIONS="-X") cause it to enter restart loop, >> surely that isn't an expected behaviour ? >> >> On Thu, 24 Jan 2019 at 13:52, Michael Stapelberg >> wrote: >> > >> > Yes, this is expected. What change are you suggesting? >> > >> > On Thu, Jan 24, 2019 at 1:45 PM Mariusz Gronczewski >> > wrote: >> >> >> >> Package: freeradius >> >> Version: 3.0.12+dfsg-5+deb9u1 >> >> Severity: normal >> >> >> >> Currently the type of systemd service is forking. >> >> >> >> Adding debug to cmdline causes freeradius to run in foreground (and dump >> >> debug >> >> to stdout), which means systemd timeouts on starting service because it >> >> assumes >> >> it will fork. >> >> >> >> Changing type to simple, and adding -f (run in foreground) option in unit >> >> file >> >> fixes that >> >> >> >> >> >> >> >> >> >> -- >> >> Mariusz Gronczewski (XANi) >> >> GnuPG: 0xEA8ACE64 >> >> >> >> ___ >> >> Pkg-freeradius-maintainers mailing list >> >> pkg-freeradius-maintain...@alioth-lists.debian.net >> >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers >> > >> > >> > >> > -- >> > Best regards, >> > Michael >> >> >> >> -- >> Mariusz Gronczewski (XANi) >> GnuPG: 0xEA8ACE64 > > > > -- > Best regards, > Michael -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64
Bug#920345: [Pkg-freeradius-maintainers] Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit
In our case it was enough to add dropin changing execstart to include -f and type to simple: ExecStart=/usr/sbin/freeradius -f $FREERADIUS_OPTIONS Type=simple What do you mean by "it is expected" ? Currently enabling debug (by setting FREERADIUS_OPTIONS="-X") cause it to enter restart loop, surely that isn't an expected behaviour ? On Thu, 24 Jan 2019 at 13:52, Michael Stapelberg wrote: > > Yes, this is expected. What change are you suggesting? > > On Thu, Jan 24, 2019 at 1:45 PM Mariusz Gronczewski wrote: >> >> Package: freeradius >> Version: 3.0.12+dfsg-5+deb9u1 >> Severity: normal >> >> Currently the type of systemd service is forking. >> >> Adding debug to cmdline causes freeradius to run in foreground (and dump >> debug >> to stdout), which means systemd timeouts on starting service because it >> assumes >> it will fork. >> >> Changing type to simple, and adding -f (run in foreground) option in unit >> file >> fixes that >> >> >> >> >> -- >> Mariusz Gronczewski (XANi) >> GnuPG: 0xEA8ACE64 >> >> ___ >> Pkg-freeradius-maintainers mailing list >> pkg-freeradius-maintain...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers > > > > -- > Best regards, > Michael -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64
Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit
Package: freeradius Version: 3.0.12+dfsg-5+deb9u1 Severity: normal Currently the type of systemd service is forking. Adding debug to cmdline causes freeradius to run in foreground (and dump debug to stdout), which means systemd timeouts on starting service because it assumes it will fork. Changing type to simple, and adding -f (run in foreground) option in unit file fixes that -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64
Bug#667616: brltty greedily grabs serial ports, ftdi_sio loses connection
2016-10-13 0:08 GMT+02:00 Samuel Thibault <sthiba...@debian.org>: > Mariusz Gronczewski, on Thu 13 Oct 2016 00:03:18 +0200, wrote: >> Hard to tell, server in question was installed from preseed file and >> it was only one having that package... > > Ok, perhaps /var/log/dpkg.log or /var/log/installer/syslog would show > the circumstances where it got installed? > > Samuel Looks like it came from installer: Start-Date: 2016-09-22 12:20:12 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install grub-common Install: gettext-base:amd64 (0.19.3-2, automatic), libpng12-0:amd64 (1.2.50-2+deb8u2, automatic), libfreetype6:amd64 (2.5.2-3+deb8u1, automatic), grub-common:amd64 (2.02~beta2-22+deb8u1), libasprintf0c2:amd64 (0.19.3-2, automatic), libfus e2:amd64 (2.9.3-15+deb8u2, automatic) End-Date: 2016-09-22 12:20:12 Start-Date: 2016-09-22 12:20:16 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install grub-pc Install: grub2-common:amd64 (2.02~beta2-22+deb8u1, automatic), grub-pc-bin:amd64 (2.02~beta2-22+deb8u1, automatic), grub-pc:amd64 (2.02~beta2-22+deb8u1), ucf:amd64 (3.0030, automatic) End-Date: 2016-09-22 12:20:17 Start-Date: 2016-09-22 12:20:25 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install brltty Install: libasound2-data:amd64 (1.0.28-1, automatic), libbluetooth3:amd64 (5.23-2+b1, automatic), libbrlapi0.6:amd64 (5.2~20141018-5, automatic), brltty:amd64 (5.2~20141018-5), libasound2:amd64 (1.0.28-1, automatic), libgpm2:amd64 (1.20.4-6.1+b2, automatic) End-Date: 2016-09-22 12:20:26 in what circumstances installer starts brltty ? My guess is that installer detected "braille" device (my usb<->1wire converter was plugged into that machine during install) on install and decided to install the package. So the problem should go away if detection is correct. IMO *if* braille device was detected but not used at all during install it it should ask if package should be installed (with no as default to not screw over automatic install). That way it would be no difference for someone using it but would allow whoever is installing it to catch any bugs like that. -- Mariusz Gronczewski (XANi) <xani...@gmail.com> GnuPG: 0xEA8ACE64
Bug#667616: brltty greedily grabs serial ports, ftdi_sio loses connection
2016-10-12 17:26 GMT+02:00 Samuel Thibault <sthiba...@debian.org>:
> Hello,
> That's still one of the things we'd need to determine.
>
> apt-cache rdepends brltty
>
> doesn't show anything that depends on or recommends brltty,
> except brltty-{espeak,flite,speechd}, which nobody depends on or
> recommends. When removing brltty, does it not uninstall anything?
>
> Samuel
Hard to tell, server in question was installed from preseed file and
it was only one having that package... but I've recently installed its
twin (same repos, same Puppet manifest, same purpose) and it didn't
had it
--
Mariusz Gronczewski (XANi) <xani...@gmail.com>
GnuPG: 0xEA8ACE64
Bug#667616: brltty greedily grabs serial ports, ftdi_sio loses connection
At this points it grabs devices that are definitely NOT a generic non-customized FTDI device, for example it grabbed my USB<->1wire adapter which had "manufacturer" and "product" field customized: Device: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice6.00 iManufacturer 1 MERA-PROJEKT iProduct2 USB <-> 1Wire (MP00202) iSerial 3 MPYRNJYY bNumConfigurations 1 and I also got it as suprise dependency to... *something* but it is hard to tell what so at least that should be fixed -- Mariusz Gronczewski (XANi) <xani...@gmail.com> GnuPG: 0xEA8ACE64
Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets
Hi, I've hit same bug, Upgrading librtmp to latest (in testing, 2.4+20151223.gitfa8646d.1-1) fixed it for me. To be exact: Unpacking librtmp1:amd64 (2.4+20151223.gitfa8646d.1-1) over (2.4+20150115.gita107cef-1) -- Mariusz Gronczewski (XANi) <xani...@gmail.com> GnuPG: 0xEA8ACE64
Bug#820796: netcfg: no way to pre-set domain and current ways of aquiring it resolve to "bad" domain
Package: netcfg Severity: important So currently domain= from boot options and netcfg/get_domain from preseed are being overwritten, which is error in itself, but even if my DHCP server is serving correct domain field, server gets configured with domain name "bad". I believe that is related to that certain subnet not having a reverse DNS but considering that: * I explictly told installer, in pre- and post-dhcp, which domain name to use * DHCP also returned correct domain name (ive checked in wireshark) it should use one of those instead of "bad" or there should be option to set it to certain domain no matter what (as that is what is needed during fully automated install)
Bug#820788: partman-auto: max partition size in recipe is ignored in LVM
Package: partman-auto
Severity: normal
I am using following preseed scheme to partition my disks (RAID1+ LVM),
partition with highest priority "eats" all of the free space even tho it
has a
max size:
d-i partman-auto-raid/recipe string \
1 2 0 ext2 /boot\
/dev/sda1#/dev/sdb1 \
. \
1 2 0 lvm - \
/dev/sda2#/dev/sdb2 \
.
d-i partman-auto/expert_recipe string\
boot-root :: \
1024 30 1024 raid \
$lvmignore{ }\
$primary{ } method{ raid } \
. \
5000 35 -1 raid \
$lvmignore{ }\
$primary{ } method{ raid } \
. \
5000 50 1 ext4 \
$defaultignore{ }\
$lvmok{ }\
lv_name{ root } \
method{ format } \
format{ }\
use_filesystem{ }\
filesystem{ ext4 } \
mountpoint{ / } \
. \
2000 50 5000 ext4 \
$defaultignore{ }\
$lvmok{ }\
lv_name{ log } \
method{ format } \
format{ }\
use_filesystem{ }\
filesystem{ ext4 } \
mountpoint{ /var/log } \
. \
1024 60 1024+10% swap \
$defaultignore{ }\
$lvmok{ }\
lv_name{ swap } \
method{ swap } \
format{ }\
.
I have also tried to set up partman-auto-lvm/guided_size to both % and in GB
but none of those leave any free space on LVM
results in:
root@debian-test:~# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync
Convert
log rootvg -wi-ao 1.86g
root rootvg -wi-ao 4.66g
swap rootvg -wi-ao 129.02g
so swap partition (I assume because of it's priority) eats all free space
(I've
tried "1024 60 2048" setting with same result) even tho max is set
Bug#818969: allow-external-password-cache seems to be a problem
using #!/bin/bash export DISPLAY=:0 perl -pe'$|=1;s/allow-external-password-cache/broken/'| /usr/bin/pinentry-gnome3 seems to "fix" it, so whatever that option is doing should be probably be disabled by default -- Mariusz Gronczewski (XANi) <xani...@gmail.com> GnuPG: 0xEA8ACE64
Bug#818969: correction
re-adding keys only helps intill gpg-agent is restarted -- Mariusz Gronczewski (XANi) <xani...@gmail.com> GnuPG: 0xEA8ACE64
Bug#818969: Info received (seems like pinentry is returning it as "cached")
Okay, it seems like anything created in earlier version in .gnupg/private-keys-v1.d/ is broken **and** doesnt signal that in any meaningful way. After removing and re-adding all keys it works fine -- Mariusz Gronczewski (XANi) <xani...@gmail.com> GnuPG: 0xEA8ACE64
Bug#818969: seems like pinentry is returning it as "cached"
ok, after trying to repeat session to pinetry from commandline I get SETKEYINFO s/aa04 OK SETDESC Please enter the passphrase for the ssh key%0A aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:f9:c5:c7%0A (.ssh/keys/arte.key) OK SETPROMPT Passphrase: OK GETPIN S PASSWORD_FROM_CACHE OK is that some uncleared cache problem ? i've been using 2.0.x befoe upgrade -- Mariusz Gronczewski (XANi) <xani...@gmail.com> GnuPG: 0xEA8ACE64
Bug#818969: gnupg-agent: gpg-agent passes not yet available when used as ssh-agent
DBG: chan_8 <- OK 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 -> GETINFO pid 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 <- D 20180 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 <- OK 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 -> SETKEYINFO s/C8E595D3AB34F640AD9B36BB91FB6407BC8EE204 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 <- OK 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 -> SETDESC Please enter the passphrase for the ssh key%0A aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:a:aa:aa:f9:c5:c7%0A (.ssh/keys/arte.key) 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 <- OK 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 -> SETPROMPT Passphrase: 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 <- OK 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 -> [[Confidential data not shown]] 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 <- [[Confidential data not shown]] 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 <- [[Confidential data not shown]] 2016-03-22 12:51:39 gpg-agent[20069] DBG: error calling pinentry: No passphrase given 2016-03-22 12:51:39 gpg-agent[20069] DBG: chan_8 -> BYE 2016-03-22 12:51:39 gpg-agent[20069] failed to unprotect the secret key: No passphrase given -- Mariusz Gronczewski (XANi) <xani...@gmail.com>
Bug#804353: puppet: disabled dnsmasq prevents puppet package from installing
Package: puppet Version: 3.8.3-1 Severity: normal After installing a package it can't be configured if dnsmasq is disabled in system: insserv: Service dnsmasq has to be enabled to start service puppet insserv: exiting now! update-rc.d: error: insserv rejected the script header dpkg: error processing package puppet (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: puppet In my use cahse puppet is NOT used in daemon mode at all and I dont think package install should trigger start. It also can't be disabled for same reason: systemctl disable puppet Synchronizing state of puppet.service with SysV init with /lib/systemd/systemd- sysv-install... Executing /lib/systemd/systemd-sysv-install disable puppet insserv: Service dnsmasq has to be enabled to start service puppet insserv: exiting now! update-rc.d: error: insserv rejected the script header -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages puppet depends on: ii init-system-helpers 1.23 ii puppet-common 3.8.3-1 ii ruby 1:2.1.5.1 ii ruby1.9.1 [ruby-interpreter] 1.9.3.484-2 ii ruby2.1 [ruby-interpreter]2.1.5-4 puppet recommends no packages. Versions of packages puppet suggests: ii etckeeper 1.18.1 pn puppet-el pn vim-puppet
Bug#727013: Bug #727013: [gnupg2] gpg2 cannot connect to pinentry, although it is installed
I have similiar problem. Config is simple i3 window manager, so no gnome services running by default except gnome keyring when I run gpg-agent either from standard /etc/ xsession or from .xsessionrc I dont get any pinentry, only immediate failure and it logs (guru loglevel): 2015-09-25 12:21:12 gpg-agent[23399] starting a new PIN Entry 2015-09-25 12:21:12 gpg-agent[23399] DBG: connection to PIN entry established 2015-09-25 12:21:12 gpg-agent[23399] DBG: error calling pinentry: Operacja anulowana 2015-09-25 12:21:12 gpg-agent[23399] failed to unprotect the secret key: Operacja anulowana 2015-09-25 12:21:12 gpg-agent[23399] failed to read the secret key 2015-09-25 12:21:12 gpg-agent[23399] ssh sign request failed: Operacja anulowana 2015-09-25 12:21:12 gpg-agent[23399] ssh request handler for sign_request (13) ready (Operacja anulowana is "operation cancelled" in english) but when I kill the daemon and run it from X11's terminal and then try to connect (after setting correct env of couse) I get pinentry correctly -- Mariusz Gronczewski (XANi) <xani...@gmail.com> GnuPG: 0xEA8ACE64
Bug#727013: Bug #727013: [gnupg2] gpg2 cannot connect to pinentry, although it is installed
Also I've noticed that my password for key doesn't work (tried to enter it at least 5 times and failed everytime and I'm 100% sure it wasnt a typo), and downgrading to 2.0.28 helped -- Mariusz Gronczewski (XANi) <xani...@gmail.com> GnuPG: 0xEA8ACE64
Bug#680660: [collectd] Bug#680660: collectd - runs as root without apparent reason
Hi, - Maybe set security bit SECBIT_NOROOT. It removes capabilities from all suid-root processes it may try to call. This would be in the spirit of the exec plugin which refuses to run any external programs / scripts as root. However, I'm not entirely sure if that's a good idea, though, as that just limits the possibilities of the user while I don't see much security benefits. Cheers, Many times I had to write silly wrappers/crons just because some stat data had to be obtained as root user. What would be nice is a ability to specify enabled capabilities per exec while allowing to run them on user root (possibly with IKnowThatIsUnsafe switch ;) ) -- Mariusz Gronczewski -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
