If you are working on cleaning up the slapd.postinst script, you may
find some of these related discussions to be interesting and/or
helpful...:
LP: #450645 error during slapd configuration: chown: cannot access
`olcDbDirectory\nolcDbDirectory'
LP: #632051 Improve slapd postinst error message in
Public bug reported:
I noticed that when my Trusty systems upgrade from resolvconf
1.69ubuntu1 to 1.69ubuntu1.1 (from trusty-updates),
/etc/init.d/resolvconf is changed from a symlink pointing to
/lib/init/upstart into a normal file containing the Debian sysinit
startup script.
Is that change
I'm not at all familiar with the net-tools source, but here's a quick
proof-of-concept patch to pull the list of interface names out of
/proc/net/dev (silently skipping any that don't support the SIOCGMIIPHY
ioctl [lo, lxcbr0, etc.]).
= first example =
./mii-tool_lp962616
enp4s0:
Public bug reported:
I recently installed the ntp package on a fairly vanilla installed-from-
DVD Xenial system, and noticed that after the package installation both
systemd-timesyncd and ntp were running:
# systemctl status ntp systemd-timesyncd.service --no-pager
ntp.service - LSB: Start NTP
Here are my current versions of the affected packages:
# dpkg -l ntp systemd | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Since Xenial now uses "predictable" interface naming schemes, mii-tool's
limit will affect most systems.
= first example =
# mii-tool
no MII interfaces found
# mii-tool $(cd /sys/class/net/; ls -d en*)
enp4s0: negotiated 100baseTx-FD, link ok
enp6s0: negotiated 1000baseT-FD flow-control,
> Upstream fix http://net-tools.git.sourceforge.net/git/gitweb.cgi?p
=net-tools/net-
tools;a=commitdiff;h=9dc3a20511a409e1de1a41d715a10028d3bc1b56
This commit can be found at this updated URL:
https://sourceforge.net/p/net-tools/code/ci/9dc3a20511a409e1de1a41d715a10028d3bc1b56/
Not that the
On Fri, Oct 19, 2018 at 14:36:35 -, Manuel López-Ibáñez wrote:
> Both of them work. I don't understand how the last command can work and
> I may still be behind a firewall.
"ntpdate -d" sends packets using an unprivileged source port, so
a firewall could allow those packets but block outgoing
On Fri, Oct 19, 2018 at 14:36:35 -, Manuel López-Ibáñez wrote:
> $ timedatectl status
> Network time on: yes
> NTP synchronized: yes
>
> So it seems it is synchronized, it just re-tries too frequently.
(I am not sure what exactly timedatectl looks at when checking the
status of ntpd, but
** Summary changed:
- Unable to change hostname
+ Unable to change hostname specified during Bionic server installation
** Also affects: subiquity (Ubuntu)
Importance: Undecided
Status: New
** Summary changed:
- Unable to change hostname specified during Bionic server installation
+
Presumably the ideal solution would be for Subiquity to hand off to
cloud-init in a manner that really only ran on that very first boot of
the new system.
However, assuming that a true fix to that situation is too invasive to
be included into Bionic at this point, it seems like it might be a good
** Also affects: ubuntu-release-notes
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to hostname in Ubuntu.
https://bugs.launchpad.net/bugs/1764172
Title:
Unable to change hostname
When installing Ubuntu Server using Subiquity (i.e. using the
ubuntu-18.04-live-server-amd64.iso installer image), the user is
prompted to enter a hostname for the new installation (along with
username/password info, etc.)
At the very end of the Subquity run, it writes this info into
(In addition to the one mentioned by WirelessMoves, I found several
other Ubuntu Forum threads as well as blog posts, etc. which recommend
working around this problem by editing the /etc/cloud/cloud.cfg file to
set the "preserve_hostname:" line's value to "true". However, that
approach means
*** This bug is a duplicate of bug 1990216 ***
https://bugs.launchpad.net/bugs/1990216
Just to have links in both directions between various bug trackers:
"connecting tinc 1.0.36/libssl3 to older nodes #414"
https://github.com/gsliepen/tinc/issues/414
** Bug watch added:
Yes, libssl3 3.0.2-0ubuntu1.11~ppa2 appears to fix the Blowfish
incompatibility (at least for the original case of connecting to Tinc
running on old distributions of Ubuntu).
Test steps:
disabled the OPENSSL_MODULES workaround I had in place on a my Jammy node, and
confirmed that Tinc was unable
On Thu, Oct 26, 2023 at 09:54:51AM -, Simon Chopin wrote:
> I'm very much against uploading this fix as an SRU. While it is a shame
> that we have interop problems with the rest of the world, fixing this in
> Jammy right now means we *will* break production for anyone that stores
>
On Tue, Oct 31, 2023 at 01:13:11PM -, Adrien Nader wrote:
> ** Description changed:
>
> === SRU information ===
> [Meta]
> - This bug is part of a series of four bugs for a single SRU.
> + This bug is part of a series of three bugs for a single SRU.
> The "central" bug with the global
On Wed, Nov 01, 2023 at 02:39:27PM -, Adrien Nader wrote:
> This one is indeed not in the SRU at the moment. The description edit
> itself did not make much sense.
(Okay, that's what I thought. For what it's worth, I noticed afterwards
that the description for LP: #2033422 still has the
On Wed, May 18, 2022 at 13:37:46 -, Simon Chopin wrote:
> Could you give more details about what happens when using the legacy
> providers?
The short version is that by enabling the legacy provider and setting
SECLEVEL to 1, I'm able to get past the "digital envelope
routines::unsupported"
On Wed, May 18, 2022 at 13:41:06 -, Simon Chopin wrote:
> Also, does tinc work in a purely Jammy context? :-)
Sorry, I just realized that I had not mentioned here on this bug the
results of my tests between various Ubuntu versions. I didn't test
Jammy-to-Jammy, but (briefly):
* Jammy
On Wed, May 18, 2022 at 13:41:06 -, Simon Chopin wrote:
> Also, does tinc work in a purely Jammy context? :-)
As far as I can determine the issue relates to compatibility between
libssl3 and the algorithms used by the Xenial-era tinc, and thus I can't
imagine Jammy-to-Jammy would be a
** Also affects: openssl (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1972939
Title:
Jammy tinc incompatibile with
On Wed, May 18, 2022 at 07:42:04 -, Simon Chopin wrote:
> I'm guessing there are some SSL certificates involved? If so, this issue
Tinc uses openssl's implementations of specific alogorithms, but does not
use either TLS or SSL certificates. (So I don't think the Tinc situation
is covered by
On Fri, Aug 05, 2022 at 00:35:32 -, Don wrote:
> It appears the issue is resolved in libssl3 3.0.4-1ubuntu1 from kinetic
> (in addition to enabling the legacy providers)
Thanks for that hint.
Can you provide any additional details on your Tinc environment and what
exactly allowed the
(I've opened LP:#1990216 to request that the fix for upstream "OpenSSL 3
cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or
CFB modes #18359" be backported to libssl3 in Jammy.)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
On Fri, Aug 05, 2022 at 00:35:32 -, Don wrote:
> It appears the issue is resolved in libssl3 3.0.4-1ubuntu1 from kinetic
> (in addition to enabling the legacy providers)
I installed a Kinetic test environment, and confirmed that I was able to
connect to my Xenial tinc (1.0.26-1) instance
On Wed, May 18, 2022 at 15:36:30 -, Nathan Stratton Treadway wrote:
> On Wed, May 18, 2022 at 13:37:46 -, Simon Chopin wrote:
> > Could you give more details about what happens when using the legacy
> > providers?
>
> The short version is that by enabling the legacy
Public bug reported:
OpenSSL upstream implemented a fix for their issue #18359 "OpenSSL 3 cannot
decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes"
https://github.com/openssl/openssl/issues/18359
as of libssl3 3.0.4 (and thus it is included in recent libssl3 versions
Seeing this warning message in Jammy, with snapd 2.58+22.04.1 installed.
** Also affects: snapd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
On Fri, Nov 24, 2023 at 12:04:59PM -, Adrien Nader wrote:
> FWIW, there's just been another report of the same issue with a
> different scenario but that's half-way between the "streaming" case and
> the "data at rest" one.
Is this report you mention an LP bug? I look through the bug list
** Description changed:
=== SRU information ===
[Meta]
- This bug was the fourth in a series of bugs for a single SRU.
- The "central" bug with the global information and debdiff is
http://pad.lv/2033422
+ (This bug was once the fourth in a series of bugs grouped for a single SRU,
with
+
On Mon, Dec 04, 2023 at 04:42:48PM -, Adrien Nader wrote:
> The affected code is in libcrypto which I think sees fewer important security
> fixes. Therefore it's possible to build it and put it in your library search
> path. This should fix the issue without being too terrible wrt security
>
On Fri, Nov 24, 2023 at 05:39:24PM -, Jeremy Sowden wrote:
> On 2023-11-24, at 17:25:11 -0000, Nathan Stratton Treadway wrote:
> > On Fri, Nov 24, 2023 at 12:04:59PM -, Adrien Nader wrote:
> > > FWIW, there's just been another report of the same issue with a
> &
** Description changed:
=== SRU information ===
[ATTENTION]
This SRU contains THREE changes which are listed in the section below.
[Meta]
This bug is part of a series of three bugs for a single SRU.
This ( #2033422 ) is the "central" bug with the global information and
debdiff.
35 matches
Mail list logo
