DuckCorp Projects: Issueshttps://projects.duckcorp.org/https://projects.duckcorp.org/favicon.ico?16699090422024-02-04T14:33:13ZDuckCorp Projects
Redmine Bip - Bug #805 (New): bipmkpw fails compilation (sometimes only?)https://projects.duckcorp.org/issues/8052024-02-04T14:33:13ZLoïc Gomez
<p>While fixing bip/adding code, I've stumbled upon these but not all the time:<br /><pre>
/usr/bin/ld: libbip.a(libbip_a-bip.o):/home/loic/code/bip/src/bip.c:60: multiple definition of `conf_log_system'; bipmkpw-bipmkpw.o:/home/loic/code/bip/src/bipmkpw.c:28: first defined here
/usr/bin/ld: libbip.a(libbip_a-bip.o):/home/loic/code/bip/src/bip.c:43: multiple definition of `conf_log_level'; bipmkpw-bipmkpw.o:/home/loic/code/bip/src/bipmkpw.c:26: first defined here
/usr/bin/ld: libbip.a(libbip_a-bip.o):/home/loic/code/bip/src/bip.c:64: multiple definition of `conf_global_log_file'; bipmkpw-bipmkpw.o:/home/loic/code/bip/src/bipmkpw.c:27: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:485: bipmkpw] Error 1
</pre></p> Bip - Bug #803 (New): /bip list connections/all_connections/all_links crashes biphttps://projects.duckcorp.org/issues/8032024-02-04T14:29:06ZLoïc Gomez
<p>In 9.4, listing connections, links crashes bip when there is a long line for on_connect_send option.<br />A fix is available.</p> Bip - Bug #793 (New): AC_PROG_LEX without either yywrap or noyywrap is obsoletehttps://projects.duckcorp.org/issues/7932024-02-02T16:48:56ZLoïc Gomez
<pre>
configure.ac:16: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete
./lib/autoconf/programs.m4:716: _AC_PROG_LEX is expanded from...
./lib/autoconf/programs.m4:709: AC_PROG_LEX is expanded from...
aclocal.m4:1072: AM_PROG_LEX is expanded from...
configure.ac:16: the top level
</pre> Bip - Bug #792 (New): Handle CAP request/reply on client connectionshttps://projects.duckcorp.org/issues/7922024-02-02T16:43:52ZLoïc Gomez
<p>Some clients will expect BIP to send a CAP reply on client connect.<br />For example, Goguma on Android will send something like this:<br /><pre>
02-02-2024 17:45:21 DEBUG: "CAP LS 302"
02-02-2024 17:45:21 DEBUG: "NICK kyoshiro"
02-02-2024 17:45:21 DEBUG: "USER kyoshiro 0 * kyoshiro"
02-02-2024 17:45:21 DEBUG: "CAP REQ sasl"
02-02-2024 17:45:21 DEBUG: "AUTHENTICATE PLAIN"
02-02-2024 17:45:21 DEBUG: "AUTHENTICATE REDACTED_B64"
02-02-2024 17:45:21 DEBUG: "CAP END"
</pre></p> DuckCorp Infrastructure - Bug #788 (New): needrestart should not restart ppp serviceshttps://projects.duckcorp.org/issues/7882024-01-08T12:29:54ZMarc Dequènesduck@duckcorp.org
<p>It causes the Internet connection to restart but that is not needed. Affects Elwing.</p> DuckCorp Infrastructure - Bug #783 (In Progress): Move Services out of Orfeohttps://projects.duckcorp.org/issues/7832023-07-09T13:51:58ZMarc Dequènesduck@duckcorp.org
Orfeo's RAID ! has one disk down, so let's move certain services out of it for now:
<ul>
<li>✅ PostgreSQL database -> Toushirou</li>
<li>✅ webmail -> Toushirou</li>
<li>✅ mailing-lists -> Toushirou</li>
<li>✅ XMPP -> Jinta</li>
<li>🔳 IRC services</li>
<li>🔳 (maybe, or later if things gets bad) NS1 & DDNS -> Toushirou</li>
</ul> DuckCorp Infrastructure - Bug #767 (New): mailman3-web internal errorhttps://projects.duckcorp.org/issues/7672022-03-27T19:49:44ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>I just tried to use mailmain3-web to remove my old email address from the the dc-admins list. I encountered an HTTP 500 (twice).<br /><pre>
ERROR 2022-03-27 21:43:42,082 1507813 postorius Mailman REST API not available
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 699, in urlopen
httplib_response = self._make_request(
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 445, in _make_request
six.raise_from(e, None)
File "<string>", line 3, in raise_from
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 440, in _make_request
httplib_response = conn.getresponse()
File "/usr/lib/python3.9/http/client.py", line 1347, in getresponse
response.begin()
File "/usr/lib/python3.9/http/client.py", line 307, in begin
version, status, reason = self._read_status()
File "/usr/lib/python3.9/http/client.py", line 276, in _read_status
raise RemoteDisconnected("Remote end closed connection without"
http.client.RemoteDisconnected: Remote end closed connection without response
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 439, in send
resp = conn.urlopen(
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 755, in urlopen
retries = retries.increment(
File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 532, in increment
raise six.reraise(type(error), error, _stacktrace)
File "/usr/lib/python3/dist-packages/six.py", line 718, in reraise
raise value.with_traceback(tb)
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 699, in urlopen
httplib_response = self._make_request(
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 445, in _make_request
six.raise_from(e, None)
File "<string>", line 3, in raise_from
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 440, in _make_request
httplib_response = conn.getresponse()
File "/usr/lib/python3.9/http/client.py", line 1347, in getresponse
response.begin()
File "/usr/lib/python3.9/http/client.py", line 307, in begin
version, status, reason = self._read_status()
File "/usr/lib/python3.9/http/client.py", line 276, in _read_status
raise RemoteDisconnected("Remote end closed connection without"
urllib3.exceptions.ProtocolError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py", line 107, in call
response = request(
File "/usr/lib/python3/dist-packages/requests/api.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in send
raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 71, in view
return self.dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/django/contrib/auth/mixins.py", line 52, in dispatch
return super().dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/django/contrib/auth/mixins.py", line 109, in dispatch
return super().dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/postorius/views/generic.py", line 74, in dispatch
return super(MailingListView, self).dispatch(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 97, in dispatch
return handler(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 183, in post
return self._member_post(request, role)
File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 135, in _member_post
self.mailing_list.unsubscribe(member)
File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/mailinglist.py", line 414, in unsubscribe
self._connection.call(path, method='DELETE')
File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py", line 135, in call
raise MailmanConnectionError(
mailmanclient.restbase.connection.MailmanConnectionError: ('Could not connect to Mailman API: ', "ConnectionError(ProtocolError('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')))")
ERROR 2022-03-27 21:43:42,091 1507813 django.request Service Unavailable: /postorius/lists/dc-admins.lists.duckcorp.org/members/member/
</pre></p> Bip - Bug #763 (New): Backlog is being lost on unstable connectionshttps://projects.duckcorp.org/issues/7632022-03-16T19:03:53ZLoïc Gomez
<p><a class="external" href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595408">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595408</a></p>
<p>Per Arnaud's comment there:</p>
<blockquote>
<p>Tcp will detect such connection breakage only when bip sends data to<br />your ADSL ip and times out waiting for ACKs. So bip indeed<br />approximates when the connection is lost. The blreset_on_talk should<br />be useful to you as bip will replay logs as long as you did not reply<br />anything.</p>
<p>I don't see any trivial way to implement a better connection loss<br />detection for backlog reset. It should be feasible to delay backlog<br />resetting to only when we receive any data from client, which would<br />prevent some errors of the type you described (but not all).<br />Another way would be to poll the tcp buffer size and to reset logs<br />only when it's down to 0. It's probably the best solution.</p>
</blockquote> Bip - Bug #762 (New): Systemctl integration does not actually stop biphttps://projects.duckcorp.org/issues/7622022-03-16T18:55:17ZLoïc Gomez
<p><a class="external" href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963907">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963907</a></p>
<p>Checked up on this but could not reproduce on Ubuntu/hirsute with a fresh start. Although, on Debian stable, it indeed shows up as dead even though restart had occurred less than 2d ago, and I remember having such issue stopping bip:<br /><pre><code>
● bip.service - Bip IRC Proxy
Loaded: loaded (/lib/systemd/system/bip.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/bip.service.d
└─custom.conf, override.conf
Active: inactive (dead) since Thu 2022-03-10 21:29:43 CET; 5 days ago
Main PID: 5508 (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 4668)
Memory: 11.4M
CPU: 1d 4h 57min 33.009s
CGroup: /system.slice/bip.service
└─5509 /usr/bin/bip -f /etc/bip/bip.conf -s /var/lib/bip
Warning: journal has been rotated since unit was started, output may be incomplete.
</code></pre></p>
<p>Couldn't find any difference in systemctl unit</p> DuckCorp Infrastructure - Bug #759 (In Progress): redmine instances don't send any notificationhttps://projects.duckcorp.org/issues/7592022-03-15T21:29:07ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>Since the redmine instances are hosted within a LXC container, email notifications are no longer sent.</p>
<p>It looks like the issue comes from the Redmine configuration and 127.0.0.1:25 being used within the container.</p>
<p>The following configuration update isn't sufficient:<br /><pre>
--- /etc/redmine/dc/configuration.yml 2022-03-15 22:28:00.095274510 +0000
+++ /etc/redmine/dc/configuration.yml.new 2022-03-15 22:27:44.102827009 +0000
@@ -4,8 +4,8 @@
email_delivery:
delivery_method: :smtp
smtp_settings:
- address: 127.0.0.1
- domain: ''
+ address: 10.0.7.1
+ domain: 'projects.duckcorp.org'
enable_starttls_auto: false
port: 25
</pre><br />due to the grey listing configuration:<br /><pre>
Mar 15 23:12:37 Toushirou postfix/smtpd[1597691]: connect from unknown[10.0.7.2]
Mar 15 23:12:37 Toushirou postfix/smtpd[1597691]: 4KJ71x5crKz4Bs: client=unknown[10.0.7.2]
Mar 15 23:12:37 Toushirou postfix/cleanup[1597693]: 4KJ71x5crKz4Bs: message-id=<redmine.journal-2400.20220315221237.3bd6c5f55c0c0d17@projects.duckcorp.org>
Mar 15 23:12:38 Toushirou postfix/cleanup[1597693]: 4KJ71x5crKz4Bs: milter-reject: END-OF-MESSAGE from unknown[10.0.7.2]: 4.7.1 Try again later; from=<issues@projects.duckcorp.org> to=<[redacted]@ir5.eu> proto=ESMTP helo=<projects.duckcorp.org>
</pre></p>
<p><a class="user active user-mention" href="https://projects.duckcorp.org/users/3">@Marc Dequènes</a> should the grey listing be disabled for 10.0.7.2 or is there another way ?</p> Bip - Bug #749 (New): bip doesn't create ~/.bip/ directory when using default PID filehttps://projects.duckcorp.org/issues/7492022-01-03T11:29:06ZLoïc Gomez
<p>30-12-2021 14:34:11 Default pid file: /home/kyoshiro/.bip/bip.pid<br />30-12-2021 14:34:11 FATAL: Cannot write to PID file (/home/kyoshiro/.bip/bip.pid.redacted.3764810) No such file or directory</p> DuckCorp Infrastructure - Bug #735 (New): Configure mail properly on Nicecity and Orthoshttps://projects.duckcorp.org/issues/7352021-10-21T05:42:49ZMarc Dequènesduck@duckcorp.org
<p>Currently the default Debian mailer (exim) is installed but not configured.</p> DuckCorp Infrastructure - Bug #722 (New): Bip cert renewal failed silentlyhttps://projects.duckcorp.org/issues/7222021-05-05T12:16:24ZMarc Dequènesduck@duckcorp.org
<p>Quack,</p>
<p>Certbot renewed the certificate properly and the hooks were run successfully too:<br /><pre>
2021-04-11 08:09:47,622:INFO:certbot.auth_handler:dns-01 challenge for irc-bouncer.duckcorp.org
2021-04-11 08:09:47,741:INFO:certbot.plugins.dns_common:Waiting 15 seconds for DNS changes to propagate
2021-04-11 08:10:02,756:INFO:certbot.auth_handler:Waiting for verification...
2021-04-11 08:10:07,523:INFO:certbot.auth_handler:Cleaning up challenges
2021-04-11 08:10:09,509:INFO:certbot.hooks:Running deploy-hook command: /etc/letsencrypt/renewal-hooks/deploy/dc_cert_renewal_deploy
2021-04-11 08:10:09,544:INFO:certbot.hooks:Running deploy-hook command: /etc/letsencrypt/renewal-hooks/deploy/dc_cert_renewal_restart_services
</pre></p>
<p>Systemd tells me the service was restarted 3 days ago:<br /><pre>
# systemctl status bip
● bip.service - Bip IRC Proxy
Loaded: loaded (/lib/systemd/system/bip.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2021-05-02 06:09:20 CEST; 3 days ago
</pre></p>
<p>But this is not true:<br /><pre>
# ps -fe | grep bip
bip 22486 1 15 Feb03 ? 13-19:29:33 /usr/bin/bip -f /etc/bip/bip.conf -s /var/lib/bip
</pre></p>
<p>So I restarted manually with systemctl:<br /><pre>
May 05 14:11:04 Thorfinn systemd[1]: Starting Bip IRC Proxy...
May 05 14:11:04 Thorfinn systemd[1]: bip.service: Found left-over process 22486 (bip) in control group while starting unit. Ignoring.
May 05 14:11:04 Thorfinn systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
May 05 14:11:04 Thorfinn systemd[1]: Started Bip IRC Proxy.
</pre><br />and the old process (22486) is still there…</p>
<p>I guess the solution would be to when the service file to avoid daemonizing with the <em>-n</em> option and switch to <em>Type=simple</em>.</p> DuckCorp Infrastructure - Bug #720 (In Progress): Bind9 KASP Migration Problemshttps://projects.duckcorp.org/issues/7202021-02-20T08:51:12ZMarc Dequènesduck@duckcorp.org
<p>This is the migration from the preliminary DNSSEC implementation called `dnssec-keymgr` to the integrated KASP scheduler with `dnssec-policy`.</p>
We encountered a few bugs or limitations (the later being expected improvements from the old system that are still dearly lacking):
<ul>
<li><a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958934" class="external">old apparmor profile in the way</a></li>
<li><del><a href="https://gitlab.isc.org/isc-projects/bind9/" class="external">does not properly import keys and states from old system</a></del>/issues/2404- fixed in 9.16.11</li>
<li><del><a href="https://gitlab.isc.org/isc-projects/bind9/" class="external">Migrating to dnssec-policy, DS is set to rumoured</a></del>/issues/2544- could not be reproduced upstream (just for reference)</li>
<li><del><a href="https://gitlab.isc.org/isc-projects/bind9/" class="external">rndc dnssec -rollover takes a <strong>very</strong> long time to be taken into account; not good for emergency rollover</a></del>/issues/2488 planned for 9.16.4 or 9.16.5-</li>
<li><a href="https://gitlab.isc.org/isc-projects/bind9/-/issues/1126" class="external">implement check if the DS record has been published</a> (should be in 9.16.19)</li>
<li><del>automatic purge of old keys</del> <em>purge-keys</em> added in 9.16.13</li>
<li><del><a href="https://gitlab.isc.org/isc-projects/bind9/" class="external">NSEC3 RRs not maintained properly; we are not affected but that's bad</a></del>/issues/2498- fixed in 9.16.12</li>
<li><a href="https://gitlab.isc.org/isc-projects/bind9/-/issues/1890" title="RFC 7344" class="external">new KSK submission hook; could be useful until registrars properly support CDS/CDNSKEY</a></li>
</ul>
Features we really need:
<ul>
<li><del>publishing of CDS/CDNSKEY</del> handled by KASP</li>
<li><del>automate using published CDS/CDNSKEY in parent zones we manage</del> created support with a crontab in the bind9 role</li>
<li>notify Bind when the DS is published/withdrawn: I guess we would need to make a script since it's probably gonna take some time before it's added upstream</li>
<li>automate using published CDS/CDNSKEY in parent zones we do not manage: currently Gandi, either with the old XMLRPC API or maybe change registrar</li>
<li>rewrite the rollover notification script for KASP (needed until all is automated and to check all is fine)</li>
</ul> DuckCorp Infrastructure - Bug #713 (New): orfeo: smartd misconfiguredhttps://projects.duckcorp.org/issues/7132020-09-18T13:16:29ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>See <code>/var/log/daemon.log</code>:<br /><pre>
Aug 18 05:16:48 Orfeo smartd[509]: Device: /dev/sg3, opened
Aug 18 05:16:48 Orfeo smartd[509]: Device: /dev/sg3, [LSILOGIC Logical Volume 3000], 72.9 GB
Aug 18 05:16:48 Orfeo smartd[509]: Device: /dev/sg3, Bad IEC (SMART) mode page, err=4, skip device
Aug 18 05:16:48 Orfeo smartd[509]: Unable to register SCSI device /dev/sg3 at line 24 of file /etc/smartd.conf
Aug 18 05:16:48 Orfeo smartd[509]: Unable to register device /dev/sg3 (no Directive -d removable). Exiting.
[...]
Aug 18 05:16:48 Orfeo systemd[1]: smartd.service: Main process exited, code=exited, status=16/n/a
Aug 18 05:16:48 Orfeo systemd[1]: smartd.service: Failed with result 'exit-code'.
</pre></p>