[Bug 1954902] [NEW] lpoptions cannot change system-wide default printer
Public bug reported: According to "man lpoptions": > When run by the root user, lpoptions gets and sets default options and > instances for all users in the /etc/cups/lpoptions file. Otherwise, > the per-user defaults are managed in the ~/.cups/lpoptions file. According to my experimentation, this is incorrect. When lpoptions is run as root, the file "/root/.cups/lpoptions" is updated (aka the personal default printer of root), not "/etc/cups/lpoptions" (aka the system-wide default printer). I'm unsure whether this is a documentation bug or wrong behavior. I assume the later, because there seems to be no other option to set the system-wide default printer. root@mi553-022:~# lsb_release -rd Description:Ubuntu 20.04.3 LTS Release:20.04 root@mi553-022:~# apt-cache policy cups cups: Installed: 2.3.1-9ubuntu1.1 Candidate: 2.3.1-9ubuntu1.1 Version table: *** 2.3.1-9ubuntu1.1 500 500 http://ftp.luis.uni-hannover.de/ubuntu focal-updates/main amd64 Packages 500 http://ftp.luis.uni-hannover.de/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2.3.1-9ubuntu1 500 500 http://ftp.luis.uni-hannover.de/ubuntu focal/main amd64 Packages 2.2.7-1ubuntu2.8 500 500 http://ftp.luis.uni-hannover.de/ubuntu bionic-security/main amd64 Packages ** Affects: cups (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1954902 Title: lpoptions cannot change system-wide default printer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1954902/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1938144] Re: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange
Thanks for building the packages for focal. I can confirm that this fixes the problem for me! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1938144 Title: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/1938144/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1938144] Re: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange
Thanks for the PPA! I currently don't have an impish system at hand, would it be possible to build it for focal as well? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1938144 Title: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/1938144/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1938144] Re: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange
Ok, I managed to reproduces this in a clean "ubuntu:latest" docker container. Steps to reproduce are below. During testing, I noticed that I aliased "ssh" to "ssh -K -X", and that "-K" (or equivalently "-o GSSAPIAuthentication=yes") is crucial. This changes the problematic SSH client command to ssh -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex root@ac3f9944f201 -v -p -o GSSAPIKeyExchange=yes -o GSSAPIAuthentication=yes -F /dev/null Complete steps to reproduce (container ac3f9944f201 is the server, IP 1.2.3.4 is the IP of the container host; this needs to be adapted): Server: podman run -it -p :,:88 ubuntu apt update apt install openssh-server krb5-kdc krb5-admin-server touch /etc/krb5kdc/kadm5.acl touch /etc/krb5kdc/kadm5.dict krb5_newrealm kadmin.local addprinc user addprinc -randkey host/ac3f9944f201 ktadd -k /etc/krb5.keytab host/ac3f9944f201 exit mkdir /run/sshd /usr/sbin/sshd -d -p -f /dev/null -o GSSAPIKeyExchange=yes -o GSSAPIAuthentication=yes Client: podman run -it ubuntu apt update apt install openssh-client krb5-user kinit user echo "1.2.3.4 ac3f9944f201" >> /etc/hosts ssh -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex root@ac3f9944f201 -v -p -o GSSAPIKeyExchange=yes -o GSSAPIAuthentication=yes -F /dev/null Notice "monitor_read: unpermitted request 48" on the server, and "Connection closed by 1.2.3.4 port " on the client (instead of the expected "permission denied). ** Changed in: openssh (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1938144 Title: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1938144/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1938144] Re: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange
Thanks Sergio for trying to reproduce this! I'm a bit puzzled, why the bug did not trigger in your case. I'll try to reproduce this in a clean VM as well now. One important thing might be that I tried to login as "root", for which I did not have a Kerberos-Ticket, so a "permission denied" would be expected, unless something like "publickey" is included in PreferredAuthentications. @Miriam: The SSH-configuration should be irrelevant, because of the options "-f /dev/null" and "-F /dev/null". The Kerberos-config could be part of this. I'll try to reproduce this on a clean machine and post better steps for reproducing afterwards. Thank you all for helping with this! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1938144 Title: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1938144/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1938144] Re: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange
Hello Athos, thanks for looking into this! This is reproducible without Ansible, that was just use-case that brought up the issue. I've further narrowed it down to the following setup: Server: /usr/sbin/sshd -d -p -f /dev/null -o GSSAPIKeyExchange=yes -o GSSAPIAuthentication=yes Client: ssh -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex root@compute-test -v -p -o GSSAPIKeyExchange=yes -F /dev/null I think this should make it independent from my local config, right? Obviously there is also Kerberos involved, which I would call configured pretty standard in our environment, but I can have a look at that config as well, if this is desired. The problem will not arise when: - The client has no valid Kerberos-Key (unset KRB5CCNAME) - If any of the the GSSAPI* options is missing on client or server - If the order of "gssapi-with-mic,gssapi-keyex" is switched (!) ** Changed in: openssh (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1938144 Title: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1938144/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1938144] [NEW] monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange
Public bug reported: I'm using openssh 1:8.2p1-4ubuntu0.2 on Ubuntu 20.04.2 LTS (client and server) with the option "GSSAPIKeyExchange=yes", and this causes the connection to fail. The server has GSSAPI (Kerberos authentication) enabled, but is is only used for non-root users (root uses SSH keys). Client command: ssh -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex root@server -v -p -o GSSAPIKeyExchange=yes Client log: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f 31 Mar 2020 debug1: Reading configuration data /home/user/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: Connecting to compute-test [130.75.80.46] port . debug1: Connection established. debug1: identity file /home/rother/.ssh/id_rsa type 0 debug1: identity file /home/rother/.ssh/id_rsa-cert type -1 debug1: identity file /home/rother/.ssh/id_dsa type -1 debug1: identity file /home/rother/.ssh/id_dsa-cert type -1 debug1: identity file /home/rother/.ssh/id_ecdsa type -1 debug1: identity file /home/rother/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/rother/.ssh/id_ecdsa_sk type -1 debug1: identity file /home/rother/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /home/rother/.ssh/id_ed25519 type -1 debug1: identity file /home/rother/.ssh/id_ed25519-cert type -1 debug1: identity file /home/rother/.ssh/id_ed25519_sk type -1 debug1: identity file /home/rother/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /home/rother/.ssh/id_xmss type -1 debug1: identity file /home/rother/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 pat OpenSSH* compat 0x0400 debug1: Authenticating to server: as 'root' debug1: Offering GSSAPI proposal: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q== debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g== debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: compression: none debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: compression: none debug1: Doing group exchange debug1: Calling gss_init_sec_context debug1: Delegating credentials debug1: Received GSSAPI_COMPLETE debug1: Calling gss_init_sec_context debug1: Delegating credentials debug1: Rekey has happened - updating saved versions debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 134217728 blocks debug1: Will attempt key: /home/rother/.ssh/id_rsa RSA SHA256:n/EY/cGjgd/r+7JpuqODxIotHHLsYptGXYx9GlKCWSM agent debug1: Will attempt key: /home/rother/.ssh/root_id_rsa RSA SHA256:yCLAID9FMILharHmDpCB8wW8eiA+iHa4oQKLODbbzKw agent debug1: Will attempt key: /home/user/.ssh/id_dsa debug1: Will attempt key: /home/user/.ssh/id_ecdsa debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk debug1: Will attempt key: /home/user/.ssh/id_ed25519 debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk debug1: Will attempt key: /home/user/.ssh/id_xmss debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs= debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Delegating credentials debug1: Delegating credentials debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-keyex Connection closed by 1.2.3.4 port Server log: debug1: sshd version OpenSSH_8.2, OpenSSL 1.1.1f 31 Mar 2020 debug1: private host key #0: ssh-rsa SHA256:REDACTED debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:REDACTED debug1: private host key #2: ssh-ed25519 SHA256:REDACTED debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='' debug1: Set /proc/self/oom_score_adj from 0 to -1000 debug1: Bind to port on 0.0.0.0. Server listening on 0.0.0.0 port . debug1: Bind to port on ::. Server listening on :: port . debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: sshd version OpenSSH_8.2, OpenSSL 1.1.1f 31 Mar 2020 debug1: private host key #0: ssh-rsa SHA256:REDACTED debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:REDACTED debu
[Bug 1818501] Re: kernel BUG at fs/ocfs2/alloc.c:1514
Unfortunately we don't have a dedicated test system here, and I don't really want to test this on the production system... I can confirm that upgrading to the HWE kernel (4.18, which contains the patches) seems to solve the problem. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818501 Title: kernel BUG at fs/ocfs2/alloc.c:1514 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818501/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818501] Re: kernel BUG at fs/ocfs2/alloc.c:1514
It should be 63de8bd9328bf2a778fc277503da163ae3defa3c ocfs2: make metadata estimation accurate and clear 71a36944042b7d9dd71f6a5d1c5ea1c2353b5d42 ocfs2: try to reuse extent block in dealloc without meta_alloc -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818501 Title: kernel BUG at fs/ocfs2/alloc.c:1514 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818501/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818501] Re: kernel BUG at fs/ocfs2/alloc.c:1514
Adding log with apport-collect files is not easily possible due to our security setup, but should not be necessary because all information can be found in the linked debian bug report. Here is our stacktrace of the bug happening: Mär 02 06:25:59 prometheus-lo kernel: [ cut here ] Mär 02 06:25:59 prometheus-lo kernel: kernel BUG at /build/linux-uQJ2um/linux-4.15.0/fs/ocfs2/alloc.c:1514! Mär 02 06:25:59 prometheus-lo kernel: invalid opcode: [#1] SMP PTI Mär 02 06:25:59 prometheus-lo kernel: Modules linked in: vhost_net vhost tap xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 devlink ebtable_filter ebtables ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm Mär 02 06:25:59 prometheus-lo kernel: xt_addrtype xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack iptable_filter ib_iser rdma_cm iw_cm ib_cm ib_core Mär 02 06:25:59 prometheus-lo kernel: CPU: 0 PID: 9345 Comm: kworker/0:1 Not tainted 4.15.0-45-generic #48-Ubuntu Mär 02 06:25:59 prometheus-lo kernel: Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 11/14/2017 Mär 02 06:25:59 prometheus-lo kernel: Workqueue: dio/dm-0 dio_aio_complete_work Mär 02 06:25:59 prometheus-lo kernel: RIP: 0010:ocfs2_grow_tree+0x5e9/0x7e0 [ocfs2] Mär 02 06:25:59 prometheus-lo kernel: RSP: 0018:bea20df37a28 EFLAGS: 00010246 Mär 02 06:25:59 prometheus-lo kernel: RAX: RBX: bea20df37da0 RCX: bea20df37bb8 Mär 02 06:25:59 prometheus-lo kernel: RDX: bea20df37ac4 RSI: bea20df37da0 RDI: 9679f54479f0 Mär 02 06:25:59 prometheus-lo kernel: RBP: bea20df37a98 R08: R09: bea20df37c58 Mär 02 06:25:59 prometheus-lo kernel: R10: bea20df37b68 R11: 0030 R12: 9676ba5d95a0 Mär 02 06:25:59 prometheus-lo kernel: R13: 9679e321d0c0 R14: 9676ba5d95a0 R15: 0001 Mär 02 06:25:59 prometheus-lo kernel: FS: () GS:9679ffc0() knlGS: Mär 02 06:25:59 prometheus-lo kernel: CS: 0010 DS: ES: CR0: 80050033 Mär 02 06:25:59 prometheus-lo kernel: CR2: 7f1b137ba3cc CR3: 0013a720a002 CR4: 007626f0 Mär 02 06:25:59 prometheus-lo kernel: DR0: DR1: DR2: Mär 02 06:25:59 prometheus-lo kernel: DR3: DR6: fffe0ff0 DR7: 0400 Mär 02 06:25:59 prometheus-lo kernel: PKRU: 5554 Mär 02 06:25:59 prometheus-lo kernel: Call Trace: Mär 02 06:25:59 prometheus-lo kernel: ? ocfs2_set_buffer_uptodate+0x34/0x490 [ocfs2] Mär 02 06:25:59 prometheus-lo kernel: ocfs2_split_and_insert+0x332/0x4d0 [ocfs2] Mär 02 06:25:59 prometheus-lo kernel: ? ocfs2_read_blocks+0x304/0x600 [ocfs2] Mär 02 06:25:59 prometheus-lo kernel: ocfs2_split_extent+0x3cb/0x530 [ocfs2] Mär 02 06:25:59 prometheus-lo kernel: ? ocfs2_dinode_set_last_eb_blk+0x20/0x20 [ocfs2] Mär 02 06:25:59 prometheus-lo kernel: ocfs2_change_extent_flag+0x25b/0x3e0 [ocfs2] Mär 02 06:25:59 prometheus-lo kernel: ocfs2_mark_extent_written+0xad/0x1c0 [ocfs2] Mär 02 06:25:59 prometheus-lo kernel: ocfs2_dio_end_io_write+0x4ec/0x690 [ocfs2] Mär 02 06:25:59 prometheus-lo kernel: ? __switch_to_asm+0x34/0x70 Mär 02 06:25:59 prometheus-lo kernel: ? ocfs2_allocate_extend_trans+0x1a0/0x1a0 [ocfs2] Mär 02 06:25:59 prometheus-lo kernel: ocfs2_dio_end_io+0x3e/0x70 [ocfs2] Mär 02 06:25:59 prometheus-lo kernel: dio_complete+0x86/0x220 Mär 02 06:25:59 prometheus-lo kernel: dio_aio_complete_work+0x19/0x20 Mär 02 06:25:59 prometheus-lo kernel: process_one_work+0x1de/0x410 Mär 02 06:25:59 prometheus-lo kernel: worker_thread+0x32/0x410 Mär 02 06:25:59 prometheus-lo kernel: kthread+0x121/0x140 Mär 02 06:25:59 prometheus-lo kernel: ? process_one_work+0x410/0x410 Mär 02 06:25:59 prometheus-lo kernel: ? kthread_create_worker_on_cpu+0x70/0x70 Mär 02 06:25:59 prometheus-lo kernel: ? do_syscall_64+0x73/0x130 Mär 02 06:25:59 prometheus-lo kernel: ? SyS_exit_group+0x14/0x20 Mär 02 06:25:59 prometheus-lo kernel: ret_from_fork+0x35/0x40 Mär 02 06:25:59 prometheus-lo kernel: Code: 00 00 00 00 00 00 10 4d 63 c6 48 c7 c1 40 26 b0 c0 ba 1c 06 00 00 48 c7 c6 f0 59 af c0 48 89 45 c0 e8 5c c2 de ff e9 41 fd ff ff <0f> 0b 48 8b 7d b8 48 85 ff 0f 84 e3 fd ff ff eb 22 3d 00 fe ff Mär 02 06:25:59 prometheus-lo kernel: RIP: ocfs2_grow_tree+0x5e9/0x7e0 [ocfs2] RSP: bea20df37a28 Mär 02 06:25:59 prometheus-lo kernel: ---[ end trace 8ba9e5d5bf1ad2c7 ]--- ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818501 Title: kernel BUG at fs/ocfs2/alloc.c:1514 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818501/+subscriptions -- ubuntu-bugs mailing li
[Bug 1818501] [NEW] kernel BUG at fs/ocfs2/alloc.c:1514
Public bug reported: The current bionic kernel (4.15) contains a known bug in the OCFS2 distributed filesystem, which can cause all nodes (!) of a redundant cluster to crash. More information on this bug (including the patch) can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841144 This fix was included upstream in 4.16, so it is included in the HWE stack, but not in the GA kernel. In my opinion this is quite severe bug, because it can bring a whole redundant setup down (this happened to us). This patch should be backported to 4.15. #cat /proc/version_signature Ubuntu 4.15.0-45.48-generic 4.15.18 # lsb_release -rd Description:Ubuntu 18.04.2 LTS Release:18.04 ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818501 Title: kernel BUG at fs/ocfs2/alloc.c:1514 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818501/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
