Bug#992120: network-manager-gnome: nm-connection-editor does not have a checkbox to enable 802.1x security
Package: network-manager-gnome Version: 1.20.0-3 Severity: normal X-Debbugs-Cc: dolphinora...@gmail.com Dear Maintainer, * What led up to the situation? Running the debian bullseye RC3 live Xfce medium. * What exactly did you do (or not do) that was effective (or ineffective)? opened the Edit connections dialog and selected 802.1x Security tab * What was the outcome of this action? dialog form was disabled/inactive. options are not selectable, and the enable checkbox is missing * What outcome did you expect instead? that options could be set up. -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-gnome depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-2 ii dbus-x11 [dbus-session-bus] 1.12.20-2 ii libatk1.0-0 2.36.0-2 ii libayatana-appindicator3-10.5.5-2 ii libc6 2.31-13 ii libcairo2 1.16.0-5 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-03.24.24-4 ii libjansson4 2.13.1-1.1 ii libmm-glib0 1.14.12-0.2 ii libnm01.30.0-2 ii libnma0 1.8.30-1 ii libnotify40.7.9-3 ii libpango-1.0-01.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libsecret-1-0 0.20.4-2 ii libselinux1 3.1-3 ii network-manager 1.30.0-2 ii policykit-1-gnome [polkit-1-auth-agent] 0.105-7 Versions of packages network-manager-gnome recommends: ii gnome-keyring3.36.0-1 ii iso-codes4.6.0-1 ii mobile-broadband-provider-info 20201225-1 ii notification-daemon 3.20.0-4 ii xfce4-notifyd [notification-daemon] 0.6.2-1 Versions of packages network-manager-gnome suggests: pn network-manager-openconnect-gnome pn network-manager-openvpn-gnome pn network-manager-pptp-gnome pn network-manager-vpnc-gnome -- no debconf information
Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout
should you not be using /tmp for that rather that /dev/shm? I think /tmp should be set up as a tmpfs and will then not persist across reboots. /var/tmp is for tmp space that needs to persist across reboots. On Thu, Jan 23, 2020 at 2:36 PM Thorsten Glaser wrote: > Package: elogind > Version: 241.3-1+debian2 > Severity: critical > Justification: breaks unrelated software > > I’m using a scheme in which I store ssh-agent and gpg-agent information > across all logins (local X session or ssh or xrdp) under /dev/shm/ since > I needed space that an unprivileged user can use and that doesn’t persist > across reboots. > > Since installing elogind, logging out from SSH sessions then on again > both breaks gpg-agent as well as makes ssh-agent instances multiply and, > thus, lose their loaded keys to the user. > > Tons of searching and debugging eventuall led me, with strace as root on > it, to the culprit: elogind > > lrwxrwxrwx 1 root root 0 Jan 23 20:21 /proc/3061/exe -> > /lib/elogind/elogind* > > 3061 unlinkat(22, "info2", 0) = 0 > 3061 unlinkat(21, ".ssh-2339", AT_REMOVEDIR) = 0 > > > Cease that instantly. This breaks unrelated software on the system, > considering that the user’s processes are still running, even if they > logged out from all ssh sessions. In particular, this will also break > software that runs as the user, dæmonised, that uses shared memory. > > If you have to clean up after yourselves, keep a list and track of the > files you created and will later need to delete. > > It might be a good idea to see whether systemd does the same and, if > so, clone this bugreport and assign the clone to them. I’m not running > systemd, so I can’t do that myself easily. > > -- System Information: > Debian Release: bullseye/sid > APT prefers unreleased > APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, > 'unstable'), (100, 'experimental') > Architecture: x32 (x86_64) > Foreign Architectures: i386, amd64 > > Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND > Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/lksh > Init: sysvinit (via /sbin/init) > > Versions of packages elogind depends on: > ii dbus 1.12.16-2 > ii debconf 1.5.73 > ii libacl1 2.2.53-5 > ii libc62.29-9 > ii libcap2 1:2.27-1 > ii libelogind0 241.3-1+debian2 > ii libselinux1 3.0-1 > ii libudev1 244-3 > ii lsb-base 11.1.0 > > Versions of packages elogind recommends: > ii libpam-elogind 241.3-1+debian2 > ii policykit-1 0.105-26 > > elogind suggests no packages. > > -- no debconf information >
Bug#743274: insserv: warns about configuration changes
I think 2 makes a lot of sense. On Fri, Jul 19, 2019, 8:27 PM Jesse Smith wrote: > This is an interesting issue. I think this is what is happening: > > 1. update-rc.d wants to disable the osspd service. To do this is creates > a file called /etc/init/osspd.override. > > 2. update-rc.d then calls insserv. insserv sees that the osspd script > normally starts in runlevels "2 3 4 & 5", but there is an override in > place preventing the script from starting. > > 3. insserv then warns about the situation, to let the user know osspd's > default runlevels have been altered. > > What makes this tricky, in my mind, is that if insserv were run as a > stand-alone program from the command line, it would be entirely correct > to warn the user that a script's defaults were overridden and its > behaviour changed. If I were to simply run "insserv" on its own, this is > what I would want. > > But in this case the update-rc.d script is calling insserv, insserv > isn't being run stand-alone. Since we just told update-rc.d to disable > osspd, and we want that override behaviour, the warning seems entirely > out of place. > > In other words, I believe both update-rc.d and insserv are behaving > correctly, and this would be proper behaviour if insserv were run on its > own. The problem is mixing the two together. > > I have two suggestions to improve the current behaviour: > > 1. update-rc.d can be edited to catch the warning. Piping output from > insserv and running it through sed or grep would avoid warnings about > scripts update-rc.d had just changed. > > 2. We can add a quiet/silent flag (maybe -q) to insserv. When that flag > is present, the program does not print out warnings. We would still > print serious errors, but not minor warnings for override situations. > Then the update-rc.d script can just call "insserv -q" to avoid extra > output like this. > > > I'm open to feedback but I think #2 is probably the best way forward for > everyone. Thoughts? > > - Jesse > >
Bug#921012: network-manager: change dependency on libpam-systemd to libpam-systemd or libpam-elogind
Package: network-manager Version: 1.14.4-4 Severity: important Dear Maintainer, Since elogind is now included in buster, can the libpam-systemd depend for network-manager be changed from libpam-systemd to libpam-systemd | libpam-elogind Thank you. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager depends on: ii adduser3.118 ii dbus 1.12.12-1 ii init-system-helpers1.56+nmu1 ii libaudit1 1:2.8.4-2 ii libbluetooth3 5.50-1 ii libc6 2.28-5 ii libcurl3-gnutls7.63.0-1 ii libglib2.0-0 2.58.2-3 ii libgnutls303.6.5-2 ii libjansson42.12-1 ii libmm-glib01.8.2-1 ii libndp01.6-1+b1 ii libnewt0.520.52.20-8 ii libnm0 1.14.4-4 ii libpam-systemd 240-4 ii libpolkit-agent-1-00.105-25 ii libpolkit-gobject-1-0 0.105-25 ii libpsl50.20.2-2 ii libreadline7 7.0-5 ii libselinux12.8-1+b1 ii libsystemd0240-4 ii libteamdctl0 1.27-1 ii libudev1 240-4 ii libuuid1 2.33.1-0.1 ii lsb-base 10.2018112800 ii policykit-10.105-25 ii udev 240-4 ii wpasupplicant 2:2.6-21 Versions of packages network-manager recommends: pn crda pn dnsmasq-base ii iptables 1.8.2-3 ii isc-dhcp-client 4.4.1-2 ii modemmanager 1.8.2-1 ii ppp 2.4.7-2+4 Versions of packages network-manager suggests: pn libteam-utils -- no debconf information
Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
Thank you. I will make sure to use a patch in the future.
On Jan 12, 2019 7:41 AM, "Dmitry Bogatov" wrote:
[ Please, next time attach patch, not whole file. Much more convenient
for review ]
[2019-01-10 10:54] Dolphin Oracle
> the buster version of sysvinit initscripts still mounts the with /run/shm
> as the mount point for the tmpfs and /dev/shm as a symlink.
>
> just adding on to the discussion...the situation actually prevents running
> certain flatpak applications.
>
> modifying mount-functions.sh per the attached will reverse the situation,
Works fine to me, I intend to accept it. Dear co-maintainers,
any objections?
> although there is still some migration code in there that strictly
speaking
> isn't necessary.
Further patches are welcome. Just remember, that not only fresh installs
must work fine, but also upgrade from stable must be smooth and painless.
Here is patch for convenience of other developers:
diff --git a/debian/src/initscripts/lib/init/mount-functions.sh
b/debian/src/initscripts/lib/init/mount-functions.sh
index 7511761c..98f53a86 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -436,7 +436,7 @@ post_mountall ()
# directory. The migration logic will then take care of the
# rest. Note that it will take a second boot to fully
# migrate; it should only ever be needed on broken systems.
- RAMSHM_ON_DEV_SHM="no"
+ RAMSHM_ON_DEV_SHM="yes"
if read_fstab_entry "/dev/shm"; then
RAMSHM_ON_DEV_SHM="yes"
fi
@@ -559,8 +559,8 @@ mount_shm ()
{
MNTMODE="$1"
- RAMSHM_ON_DEV_SHM="no"
- SHMDIR="/run/shm"
+ RAMSHM_ON_DEV_SHM="yes"
+ SHMDIR="/dev/shm"
if read_fstab_entry "/dev/shm"; then
if [ "$MNTMODE" = "mount_noupdate" ]; then
log_warning_msg "Warning: fstab entry for /dev/shm;
should probably be for /run/shm unless working around a bug in the Oracle
database"
@@ -706,13 +706,3 @@ is_fastboot_active() {
done
return 1
}
Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
the buster version of sysvinit initscripts still mounts the with /run/shm as the mount point for the tmpfs and /dev/shm as a symlink. just adding on to the discussion...the situation actually prevents running certain flatpak applications. modifying mount-functions.sh per the attached will reverse the situation, although there is still some migration code in there that strictly speaking isn't necessary. mount-functions.sh-testing-antix-rev1.tar.gz Description: GNU Zip compressed data
