Re: Bookworm upgrade, usrmerge failure
Le lundi 12 juin 2023 à 14:02 -0400, Jeffrey Walton a écrit : > On Mon, Jun 12, 2023 at 5:48 AM Bastien Durel > wrote: > > > > Hello, > > > > During bookworm upgrade, I ran into some usrmerge failures, which > > led > > to an hard-to-fix situation > > > > Paramétrage de usrmerge (35) ... > > > > FATAL ERROR: > > Both /lib/x86_64-linux-gnu/libidn.so.11 and /usr/lib/x86_64-linux- > > gnu/libidn.so.11 exist. > > > > You can try correcting the errors reported and running again > > /usr/lib/usrmerge/convert-usrmerge until it will complete without > > errors. > > Do not install or update other Debian packages until the program > > has been run successfully. > > > > E: usrmerge failed. > > > > root@corrin:/root # /usr/lib/usrmerge/convert-usrmerge > > /usr/bin/perl: /lib/x86_64-linux-gnu/libm.so.6: version > > `GLIBC_2.29' not found (required by /usr/bin/perl) > > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version > > `GLIBC_2.28' not found (required by /usr/bin/perl) > > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version > > `GLIBC_2.33' not found (required by /usr/bin/perl) > > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version > > `GLIBC_2.34' not found (required by /usr/bin/perl) > > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version > > `GLIBC_2.25' not found (required by /lib/x86_64-linux- > > gnu/libcrypt.so.1) > > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version > > `GLIBC_2.36' not found (required by /lib/x86_64-linux- > > gnu/libcrypt.so.1) > > root@corrin:/root # rm /usr/lib/x86_64-linux-gnu/libidn.so.11 > > Erreur de segmentation (core dumped) > > root@corrin:/root # ls -l /usr/lib/x86_64-linux-gnu/libidn.so.11 > > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found > > (required by ls) > > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found > > (required by /lib/x86_64-linux-gnu/libselinux.so.1) > > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not found > > (required by /lib/x86_64-linux-gnu/libselinux.so.1) > > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found > > (required by /lib/x86_64-linux-gnu/libselinux.so.1) > > > > As no system tool was usable in this situation (dpkg crashed too), > > I > > powered-off the machine and restored it from backup. I then > > installed > > usrmerge on bullseye, fixed the problems, then done the bookworm > > upgrade without any other problems. > > > > As usrmerge is mandatory on bookworm ; and usrmerge failure during > > upgrade leads to (could lead to ?) big problems ; shouldn't its > > installation be advised in 4.1 or 4.2 chapters of the upgrade guide > > ? > > > > I know 5.1.14 says merged-/usr is now required ; but it does not > > warn > > about failures, and I don't think I'm the only one who don't read > > the > > next chapter before starting upgrade ;) > > I wonder if you have a bunch of stale symlinks... > > Does symlinks report any dangling links for the problem shared > libraries? > > sudo symlinks -r / | grep dangling > > If the list of dangling looks safe to clean-up, then you can run > > sudo symlinks -r -d / > > Jeff > Hello. I have a bunch of them, here a those in /usr : dangling: /usr/bin/rust-llvm-dwp -> llvm-dwp-14 dangling: /usr/bin/clhsdb -> /etc/alternatives/clhsdb dangling: /usr/bin/rust-lld -> lld-14 dangling: /usr/bin/rust-clang -> clang-14 dangling: /usr/bin/x-terminal-emulator -> /etc/alternatives/x-terminal-emulator dangling: /usr/bin/hsdb -> /etc/alternatives/hsdb dangling: /usr/share/phpmyadmin/docs/html -> ../../doc/phpmyadmin/html dangling: /usr/share/man/man1/policyeditor.1.gz -> /etc/alternatives/policyeditor.1.gz dangling: /usr/share/man/man1/itweb-settings.1.gz -> /etc/alternatives/itweb-settings.1.gz dangling: /usr/share/man/man1/x-terminal-emulator.1.gz -> /etc/alternatives/x-terminal-emulator.1.gz dangling: /usr/share/man/man3/SSL.3ssl.gz -> ssl.3ssl.gz dangling: /usr/share/man/man3/cerfcf.3.gz -> cerf.3.gz dangling: /usr/share/man/man3/cerfcl.3.gz -> cerf.3.gz dangling: /usr/share/man/man3/cerfl.3.gz -> cerf.3.gz dangling: /usr/share/man/man3/cerff.3.gz -> cerf.3.gz dangling: /usr/share/pyshared/paste/evalexception/media/MochiKit.packed.js -> ../../../../javascript/mochikit/MochiKit.js dangling: /usr/share/emacs/site-lisp/elpa/php-mode-1.23.0/php-util-buffer.el -> /usr/share/emacs/site-lisp/elpa-src/php-mode-1.23.0//php-util-buffer.el dangling: /u
Bookworm upgrade, usrmerge failure
Hello, During bookworm upgrade, I ran into some usrmerge failures, which led to an hard-to-fix situation Paramétrage de usrmerge (35) ... FATAL ERROR: Both /lib/x86_64-linux-gnu/libidn.so.11 and /usr/lib/x86_64-linux-gnu/libidn.so.11 exist. You can try correcting the errors reported and running again /usr/lib/usrmerge/convert-usrmerge until it will complete without errors. Do not install or update other Debian packages until the program has been run successfully. E: usrmerge failed. root@corrin:/root # /usr/lib/usrmerge/convert-usrmerge /usr/bin/perl: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/bin/perl) /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /usr/bin/perl) /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /usr/bin/perl) /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /usr/bin/perl) /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /lib/x86_64-linux-gnu/libcrypt.so.1) /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not found (required by /lib/x86_64-linux-gnu/libcrypt.so.1) root@corrin:/root # rm /usr/lib/x86_64-linux-gnu/libidn.so.11 Erreur de segmentation (core dumped) root@corrin:/root # ls -l /usr/lib/x86_64-linux-gnu/libidn.so.11 ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by ls) ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /lib/x86_64-linux-gnu/libselinux.so.1) ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not found (required by /lib/x86_64-linux-gnu/libselinux.so.1) ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /lib/x86_64-linux-gnu/libselinux.so.1) As no system tool was usable in this situation (dpkg crashed too), I powered-off the machine and restored it from backup. I then installed usrmerge on bullseye, fixed the problems, then done the bookworm upgrade without any other problems. As usrmerge is mandatory on bookworm ; and usrmerge failure during upgrade leads to (could lead to ?) big problems ; shouldn't its installation be advised in 4.1 or 4.2 chapters of the upgrade guide ? I know 5.1.14 says merged-/usr is now required ; but it does not warn about failures, and I don't think I'm the only one who don't read the next chapter before starting upgrade ;) Regards, -- Bastien
Re: Passwords
Le mardi 17 janvier 2023 à 09:51 +0100, DdB a écrit : > Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov: > Everyone (and their friend) seem to know, how to work around this, > which > apparently is common debian knowledge (which is nice). > > But somehow, i feel there could be more caring about avoiding to > teach > future hackers by accident. Is this kind of lesson appropriate for a > users list? - I doubt it. Local user is king. They can change boot-loader, extract disks to put them in another computer ... Not only Debian-related, much computer- related ^^ To prevent that, you should encrypt your disks, so no-one can mount them and change your passwords/read your data. (But you won't recover for lostt passphrase, then ;)) Regards, -- Bastien
Re: Debian: LDAP migration
Le jeudi 26 août 2021 à 17:54 +0300, IL Ka a écrit : > 1. Export your data to LDIF using `slapcat` > https://www.openldap.org/software/man.cgi?query=slapcat > > 2. Install Debian 11 with OpenLDAP on some test machine > 3. import LDIF using `ldapadd` or `ldapmodify` and see if it works > https://www.digitalocean.com/community/tutorials/how-to-use-ldif-files-to-make-changes-to-an-openldap-system > > The most safe approach imho. > `slapadd` to import a `slapcat` dump ;) -- Bastien
Re: Debian: LDAP migration
Le jeudi 26 août 2021 à 16:02 +0200, Dieter Heußner a écrit : > My aim is that the LDAP server runs on a supported Debian version > (v10 or > v11). As far as I understand the IT situation with respect to LDAP > server, > there are two alternatives: > 1. Upgrade LDAP server from Debian v6.0.4 to v6.10, then to v10 (via > v7, v8 > and v9). Later on to v11. > 2. Install a new LDAP server based on Debian v11 (from scratch) and > migrate > the current LDAP configuration to the new LDAP server. > > I reckon that both variants have their pros and cons. > What are your recommendations? Any hints? Any caveats? > Who DID migrate a LDAP configuration from an unsupported Debian > version to a > supported one? How did you achieve it? > Hello, As the DEB82 ldap (probably) uses an unsupported backend (bdb), you would have to backup/trash/restore your database to switch to a supported one (mdb). So I'd take the new (11) install. NB: I did not try the migration at once, as I've done each one soon after release, but my config date back the 6 or 7 area (I even have a flat slapd.conf on consumer node) Regards, -- Bastien signature.asc Description: This is a digitally signed message part
Re: dbus-deamon avoiding reboot after upgrade
Le lundi 19 août 2019 à 10:15 -0400, Greg Wooledge a écrit : > On Mon, Aug 19, 2019 at 11:41:33AM +0200, Bastien Durel wrote: > > Ok, there muste have been an error somewhere ... > > > > root@corrin-2:~# apt-cache policy systemd-container > > systemd-container: > > Installed: (none) > > Candidate: 241-5 > > Version table: > > 241-5 500 > > 500 http://ftp.fr.debian.org/debian buster/main amd64 > > PackagesPackages > > root@corrin-2:~# dpkg -S /usr/bin/systemd-nspawn > > dpkg-query: no path found matching pattern /usr/bin/systemd-nspawn > > Are you saying that you installed systemd-nspawn from something other > than a Debian package, *and* you put it in the /usr/bin directory? > That's a really poor decision -- local add-ons should be in > /usr/local > or in /opt. > > Also, it appears you were relying on various dependenent packages, > like > dbus, without knowing it, since the thing that was actually using > them > wasn't installed via the packaging system. That's something you will > have to track yourself. There's no way apt can do it for you. > No, I had a problem during the jessie > strech migration, which leds to /var/lib/dpkg corruption. I "recovered" via a manual re-installation of all jessie deb files found in /var/cache/apt, but some packages seems to have been missing from dpkg index, despite beeing installed. I found a few other files related to non-recorded jessie packages in /usr/bin, like /usr/bin/pydoc3.4 or /usr/bin/mutt-org [1] I re-installed some of the packages, purged some others, and I won't do a full reinstall because I'm too lazy ;) [1] https://paste.debian.net/1096576/ -- Bastien
Re: dbus-deamon avoiding reboot after upgrade
Le lundi 19 août 2019 à 11:54 +0300, Reco a écrit : > Hi. > > On Mon, Aug 19, 2019 at 10:23:54AM +0200, Bastien Durel wrote: > > Le lundi 19 août 2019 à 10:37 +0300, Reco a écrit : > > > > $ apt purge dbus -s > > > <...> > > > >dbus* libpam-systemd* > > > > > > So, dbus is not needed there. > > > > Hello. Same here, but with dbus removed, my jobs using systemd- > > nspawn > > fails with: > > > > Failed to open system bus: Connection refused > > > > So testing your system after removal may be a good idea, apt > > insight is > > not sufficient ;) > > $ apt show systemd-container | grep dbus > Depends: libacl1 (>= 2.2.23), ..., dbus > > apt cannot help you if you're using it wrong. > > Reco > Ok, there muste have been an error somewhere ... root@corrin-2:~# apt-cache policy systemd-container systemd-container: Installed: (none) Candidate: 241-5 Version table: 241-5 500 500 http://ftp.fr.debian.org/debian buster/main amd64 PackagesPackages root@corrin-2:~# dpkg -S /usr/bin/systemd-nspawn dpkg-query: no path found matching pattern /usr/bin/systemd-nspawn :/ -- Bastien
Re: dbus-deamon avoiding reboot after upgrade
Le lundi 19 août 2019 à 10:37 +0300, Reco a écrit : > > $ apt purge dbus -s > <...> > >dbus* libpam-systemd* > > So, dbus is not needed there. Hello. Same here, but with dbus removed, my jobs using systemd-nspawn fails with: Failed to open system bus: Connection refused So testing your system after removal may be a good idea, apt insight is not sufficient ;) -- Bastien
Re: Permanent Use of IPv4
Le vendredi 15 février 2019 à 10:12 -0500, Stephen P. Molnar a écrit : > Thanks for help from this gropup I can force the use of IPv4 by > running: sysctl -w net.ipv6.conf.all.disable_ipv6=1. > > For a number of reasons I have just done a fresh install of Stretch, > hoping that the installer woould allow me to select IPv4, which, of > course it didn't. > > Although I have been using Linux since the early days of Slackware, I > am > not a hardware or OS person. > > My question is how can I implement the sysctl statement on boot? > > Thanks in advance. > Hello. Put it in a .conf file under /etc/sysctl.d/ See /etc/sysctl.d/README.sysctl Regards, -- Bastien
Re: certbot options
Le mercredi 28 novembre 2018 à 13:29 +, Michael Grant a écrit : > In /lib/systemd/system/certbot.service > > The line to start certbot is: > ExecStart=/usr/bin/certbot -q renew > > If I modify this file by hand: > > ExecStart=/usr/bin/certbot -q --pre-hook /usr/local/bin/certbot- > prehook.sh renew > > The next time certbot is updated by apt, this file gets overwritten > and my change goes away. > > Could someone please tell me the proper place to modify certbot’s > default arg list or is there some systemctl command I should be doing > instead of modifying this file directly? Or is this a bug and > apt-get should warn me before overwriting this file on update? > Hello, You can put an override file in /etc/systemd/system/certbot.service.d/override.conf systemctl edit certbot.service should create it for you -- Bastien
Re: Kernel hang in Xen (4.9)
Le 20/08/2018 à 11:58, Steve Kemp a écrit : I have a xen guest that hangs after a while if running 4.9 kernel (since upgrade to stretch) You might try the 4.9.110-3 kernel from stretch-proposed-updates, which I noticed is required to fix a reboot-loop on stretch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903767 That doesn't seem to match your situation 100% as you do seem to gain access, albeit briefly, but it might be worth a go. I've noticied that, and tried to run 4.9.110-3+deb9u2 as 4.9.110-3 is out from stretch-proposed-updates. I ran 4.9.110-3 too, same problem. (and almost every 4.9 version that where in repo since stretch is out, got a freeze each time, had to fallback each time) When running on jessie's 3.16 kernel, the guest is running fine. I have other VMs on this host running 4.9 kernel without problem. It is interesting that not all guests fail .. Indeed, it is. But I don't figure WHY this guest fails. And as it's the "put-it-here-if-there-is-no-obvious-choice" machine of my network, there's many installed services on it. -- Bastien
Kernel hang in Xen (4.9)
Hello, I have a xen guest that hangs after a while if running 4.9 kernel (since upgrade to stretch) I get theses messages in console, then I cannot do anything. I get a login prompt on console, but do not get shell prompt; SSH connexion is established, I get my motd (even with updated last login time), but no shell. [260514.780118] INFO: task jbd2/xvda5-8:192 blocked for more than 120 seconds. [260514.780132] Not tainted 4.9.0-7-amd64 #1 Debian 4.9.110-3+deb9u2 [260514.780137] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [260514.780145] jbd2/xvda5-8D0 192 2 0x [260514.780156] 8800f1caec00 8800f0beb140 8800f5c18980 [260514.780171] 81c11500 c900410bba70 8160fed9 81090d5a [260514.780183] 00ffe8c0b000 8800f5c18980 8130f759 8800f0beb140 [260514.780196] Call Trace: [260514.780239] [] ? __schedule+0x239/0x6f0 [260514.780249] [] ? queue_work_on+0x2a/0x40 [260514.780263] [] ? blk_mq_flush_plug_list+0x139/0x160 [260514.780271] [] ? bit_wait+0x50/0x50 [260514.780278] [] ? schedule+0x32/0x80 [260514.780286] [] ? schedule_timeout+0x1dd/0x380 [260514.780295] [] ? xen_clocksource_get_cycles+0x11/0x20 [260514.780303] [] ? bit_wait+0x50/0x50 [260514.780310] [] ? io_schedule_timeout+0x9d/0x100 [260514.780319] [] ? prepare_to_wait+0x57/0x80 [260514.780326] [] ? bit_wait_io+0x17/0x60 [260514.780333] [] ? __wait_on_bit+0x55/0x80 [260514.780344] [] ? find_get_pages_tag+0x158/0x2e0 [260514.780353] [] ? wait_on_page_bit+0x7f/0xa0 [260514.780360] [] ? wake_atomic_t_function+0x60/0x60 [260514.780370] [] ? __filemap_fdatawait_range+0xe0/0x140 [260514.780378] [] ? filemap_fdatawait_range+0xf/0x30 [260514.780397] [] ? jbd2_journal_commit_transaction+0x73d/0x17b0 [jbd2] [260514.780408] [] ? __switch_to_asm+0x34/0x70 [260514.780416] [] ? __switch_to_asm+0x40/0x70 [260514.780424] [] ? xen_load_sp0+0x84/0x170 [260514.780432] [] ? finish_task_switch+0x7d/0x200 [260514.780440] [] ? _raw_spin_unlock_irqrestore+0x16/0x20 [260514.780452] [] ? kjournald2+0xc2/0x260 [jbd2] [260514.780463] [] ? prepare_to_wait_event+0xf0/0xf0 [260514.780474] [] ? commit_timeout+0x10/0x10 [jbd2] [260514.780482] [] ? kthread+0xd9/0xf0 [260514.780489] [] ? kthread_park+0x60/0x60 [260514.780496] [] ? ret_from_fork+0x57/0x70 When running on jessie's 3.16 kernel, the guest is running fine. I have other VMs on this host running 4.9 kernel without problem. Does anyone have an idea about this bug ? Thanks, -- Bastien
Re: Kernel for Spectre and Meltdown
Le lundi 29 janvier 2018 à 07:52 +, Dextin Jerafmel a écrit : > Hello > > I've installed Debian 9.3 about one and a half month ago . I'm newbie > to Linux world > My Kernel was 4.9.0.3 at the first of installation . After upgrading > ( sudo apt upgrade ) it becomes 4.9.0.4 > But in Your site You've mentioned Kernel for Debian Stretch is 4.9.65 > and You updated it for Spectre and Meltdown bugs > I tried to search for available Kernel images but there isn't any > newer Kernel than 4.9.0.5 > > Please guide me > > Thanks a lot > Hello. Debian kernel versionning doesn't match kernel version itself. You should see it via dpkg -s: $ dpkg -s linux-image-4.9.0-5-amd64 Package: linux-image-4.9.0-5-amd64 Status: install ok installed Priority: optional Section: kernel Installed-Size: 185320 Maintainer: Debian Kernel Team Architecture: amd64 Source: linux Version: 4.9.65-3+deb9u2 ^^ Depends: kmod, linux-base (>= 4.3~), initramfs-tools (>= 0.120+deb8u2) | linux-initramfs-tool Recommends: firmware-linux-free, irqbalance Suggests: linux-doc-4.9, debian-kernel-handbook, grub-pc | grub-efi- amd64 | extlinux Breaks: initramfs-tools (<< 0.120+deb8u2), xserver-xorg-input-vmmouse (<< 1:13.0.99) Description: Linux 4.9 for 64-bit PCs The Linux kernel 4.9 and modules for use on PCs with AMD64, Intel 64 or VIA Nano processors. . This kernel also runs on a Xen hypervisor. It supports both privileged (dom0) and unprivileged (domU) operation. Homepage: https://www.kernel.org/ As you can see, linux-image-4.9.0-5-amd64 is kernel 4.9.65 -- Bastien Durel
Re: java, javac versions not the same, apt-get doesn't help ...
Le vendredi 12 janvier 2018 à 04:20 -0500, Albretch Mueller a écrit :
> java gives you error messages when you compile and run code with
> different versions of the JVM
>
> while trying to update my box using apt-get I am getting:
> "openjdk-8-jdk is already the newest version."
>
> How do you make sure you install the same version of both java and
> javac using apt-get?
>
> lbrtchx
> ~
> $ uname -a
> Linux IBMThnkPdT60 3.16.0-4-686-pae #1 SMP Debian 3.16.36-1+deb8u1
> (2016-09-03) i686 GNU/Linux
>
> $ java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1~bpo8+1-b11)
> OpenJDK Server VM (build 25.131-b11, mixed mode)
>
> $ javac -version
> javac 1.7.0_111
>
>
> # _LOG_FL="openjdk-8-jdk_install_$(date +%Y%m%d%H%M%S).log"
>
> # uname -a >> "${_LOG_FL}" 2>&1
>
> # time(apt-get -V install openjdk-8-jdk) >> "${_LOG_FL}" 2>&1
>
> # cat openjdk-8-jdk_install_20180112040601.log
> Linux IBMThnkPdT60 3.16.0-4-686-pae
> #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) i686 GNU/Linux
>
> Reading package lists...
> Building dependency tree...
> Reading state information...
> openjdk-8-jdk is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 365 not upgraded.
>
> real0m3.571s
> user0m0.672s
> sys 0m0.092s
>
> # java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1~bpo8+1-b11)
> OpenJDK Server VM (build 25.131-b11, mixed mode)
>
> # javac -version
> javac 1.7.0_111
>
You d'like to look at your alternatives
$ ls -l /etc/alternatives/java*
lrwxrwxrwx 1 root root 46 juil. 2 2017 /etc/alternatives/java ->
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
lrwxrwxrwx 1 root root 56 juil. 2 2017 /etc/alternatives/java.1.gz ->
/usr/lib/jvm/java-8-openjdk-amd64/jre/man/man1/java.1.gz
lrwxrwxrwx 1 root root 39 déc. 14 2010 /etc/alternatives/java_vm ->
/usr/lib/jvm/java-6-sun/jre/bin/java_vm
lrwxrwxrwx 1 root root 38 déc. 14 2010 /etc/alternatives/javaws ->
/usr/lib/jvm/java-6-sun/jre/bin/javaws
lrwxrwxrwx 1 root root 48 déc. 14 2010 /etc/alternatives/javaws.1.gz
-> /usr/lib/jvm/java-6-sun/jre/man/man1/javaws.1.gz
On this box, java and javaws use different java versions
You can set them using update-alternatives(1) -- or update-java-
alternatives(8) for java
--
Bastien
Re: Apache oddness on jessie => stretch upgrade
Le mardi 22 août 2017 à 03:58 -0500, Dave Sherohman a écrit : > [...] > Also, side question: I'm also manually running `systemctl enable > apache2` after upgrading. How can you tell whether something is > enabled > or not in systemd? `systemctl status` will tell you whether it's > currently running or not, but I can't find any indication of enabled/ > disabled in its output. > Hello. Second line of systemctl status output: Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) or for disabled service: Loaded: loaded (/lib/systemd/system/bgpd.service; disabled; vendor preset: enabled) -- Bastien
Re: Unusual LUKS setup
Le lundi 14 août 2017 à 17:35 +0200, Nicolas George a écrit : > Le septidi 27 thermidor, an CCXXV, Bastien Durel a écrit : > > You don't. pam_mount will ask you for your password (after ssh > > authentication) if you didn't provided one > > Thanks for the clarification. If you are right, then you probably > should > file a bug report for outdated documentation. > > But still, "UsePrivilegeSeparation no" is a deal breaker on its own. > > Regards, > In my setup (openssh 7.5), there is no UsePrivilegeSeparation setting, it's on by default. And pam_mount is able to mount my encrypted partitions when I log via SSH. Regards, -- Bastien
Re: Unusual LUKS setup
Le lundi 14 août 2017 à 16:17 +0200, Nicolas George a écrit : > - If you use SSH, you have to adjust /etc/ssh/sshd_config like this: > > UsePAM yes > UsePrivilegeSeparation no > ChallengeResponseAuthentication no > PasswordAuthentication yes You don't. pam_mount will ask you for your password (after ssh authentication) if you didn't provided one -- Bastien
Re: IPv6 and DNS
Le mercredi 13 juillet 2011 à 20:48 +1000, Andrew McGlashan a écrit : > Hi, [...] > Many using 3G USB modems are opening themselves up to abuse if (by > default) having their machines directly connected to the Internet. Any > machine that is directly accessible via the Internet _must_ have > suitable security, ie a restrictive firewall at least. I can just > imagine all the Windows laptops (well, not just Windows, but hey), > becoming owned just because they are using a 3G USB modem directly on > their machine without a firewall -- this will be amplified for those on > ANY network that has open slather via IPv6 addressing. NAT-like "security" may be enabled with 2 rules on the router/firewall ISPs send to their customers. ip6tables -A INPUT -i wan -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A INPUT -i wan -j DROP Actually you need to accept some icmpv6 packets, then we need another rule ;) If ISPs sent their modem/box/router/whatever properly configured (default configuration disallowing incoming connections), there is no more security issues than with the ipv4/NAT setup. -- Bastien Durel -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1310558568.2356.24.camel@data-dev4
