Just locked out of an AWS machine again due to this bug. Any news on a
fix?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/1847902
Title:
pam_nologin should optionally exclude
Dictating to people what their PKI policy should be is outside the scope
of apt. Apt must behave properly as per standard unix behaviour, with a
proper working user and a proper working group. Trying to dictate
directory permissions to people breaks automation, breaks orchestration,
and makes it re
9 years later and this bug is still unfixed when building from Bionic.
The error
Error: signing key fingerprint does not exist
Failed to add key.
might be a statement of fact, but it doesn't tell me what I must do, or
whether my system is broken or not, or what action I must take.
--
You recei
Deploy Ubuntu Bionic machine from AWS, try and log in:
"System is booting up. See pam_nologin(8)"
Given it is impossible to log in, it's impossible to see what's wrong,
or fix it.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
In our case it burned a number of days of dev time, so this is
definitely causing pain.
We've never seen this before because until docker, we have not
encountered a system where apt-transport-https wasn't installed by
default.
--
You received this bug notification because you are a member of Ubu
Is it possible to backport this to trusty too? This bit us hard, and
there are a lot of people out there posting this problem but with no
solution.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.la
Public bug reported:
When "apt-get update" is run on a docker container running Ubuntu v16.04
and containing an additional apt source repository hosted on an https
webserver, the "apt-get update" command hangs.
The hang happens after connections to http ubuntu hosts are complete,
and apt-get rema
More details.
The ClientHello packet in this case is larger than 255 bytes, and is
triggering the handshake failure in one of two ways.
When psql linked to openssl v1.0.1f attempts to connect to postgresql
linked to openssl v1.0.1f, the client side sends 8 bytes, then 1 byte,
then 305 bytes in my
I've also slammed headlong into this one.
The clue is "SSL handshake has read 0 bytes and written 317 bytes"
What the openssl v1.0.1f client side is doing is sending a clienthello
packet larger than 255 bytes to a broken SSL implementation, which slams
the phone down on you, thus "read 0 bytes".
Using openssl s_client on a MacOS Sierra machine connecting to the same
postgresql server, the failure is identical.
Looks like whatever is triggering this is caused by the server, but is
being failed by the client.
--
You received this bug notification because you are a member of Ubuntu
Touch s
ssldump looks like the below.
>From ssldump, we can see that the server sent three separate
certificates. Openssl s_client however claims that no certificates were
detected.
New TCP connection #42: 172.29.231.43(33116) <-> 172.29.228.240(5432)
42 1 0.0038 (0.0038) C>SV3.1(300) Handshake
C
Despite printing "no peer certificate available" below, the postgresql
server serves three certificates (two intermediates and a leaf) as
picked up by ssldump.
In this case it is the client side that is triggering the handshake
failure, not the server. The client side refuses to add the cause of t
I am seeing the exact same bug, only with the server being postgresql
instead of openldap.
The same setup and certificates works fine on Trusty, but have regressed
on Xenial.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to op
I am seeing this bug in Ubuntu v14.04. No obvious cause. When it's
happened we've physically replaced the instances, as there is no console
access at AWS.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
http
Public bug reported:
Configure an Ubuntu Trusty machine with sssd against an LDAP domain.
This fails as follows:
ubuntu@bastion01:~$ /usr/bin/sss_ssh_authorizedkeys [username]
(Wed Mar 22 17:46:15:940434 2017) [/usr/bin/sss_ssh_authorizedkeys] [main]
(0x0020): set_locale() failed (5): Input/outp
We are currently on a deadline and were forced to switch to CentOS7 to
move our project forward, which worked fine out the box.
Once our deadline is over I will run tests on the above packages to see
what difference they make.
--
You received this bug notification because you are a member of Ubu
16 matches
Mail list logo
