Re: [gentoo-user] eix doesn't ignore disabled overlays
Am Montag, 11. März 2019, 23:35:35 CET schrieb Marc Joliet: > Am Montag, 11. März 2019, 10:48:38 CET schrieb Helmut Jarausch: > > Hi, > > > > eix-sync and eix-diff reports (newer) packages from disabled overlays > > (via layman -D ...). > > How can I tell eix to ignore these? > > > > I'm using eix GIT from 2019/03/06. > > > > Many thanks for a hint, > > Helmut > > Did you already run eix-update? If so, I suspect you found a bug. > > HTH Sorry, forget that, eix-sync already runs eix-update and I have no experience with layman's disable feature, so I can't help you there. I don't have time right now, but if I did, I would find out how layman disables overlays exactly (by modifying repos.d?) and compare that with how eix finds overlays. Maybe layman doesn't make them invisible to eix, or maybe eix isn't correct enough in how it finds overlays, but either way it sounds to me like there's some friction between them. HTH -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] eix doesn't ignore disabled overlays
Am Montag, 11. März 2019, 10:48:38 CET schrieb Helmut Jarausch: > Hi, > > eix-sync and eix-diff reports (newer) packages from disabled overlays > (via layman -D ...). > How can I tell eix to ignore these? > > I'm using eix GIT from 2019/03/06. > > Many thanks for a hint, > Helmut Did you already run eix-update? If so, I suspect you found a bug. HTH -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Ssh problem : half-solved
On Mon, 11 Mar 2019 21:35:54 +, Mick wrote: > > > > It shows that ssh is reading your config file, but not picking up > > > > the options for this host. I would expect to see something like > > > > > > > > debug1: Reading configuration data /home/nelz/.config/ssh > > > > debug1: /home/nelz/.config/ssh line N: Applying options for > > > > > > > > Do you have any other Host stanzas in the config? > > > > > > Check both config files for conflicts: > > > > > > /home/purslow/.ssh/config > > > /etc/ssh/ssh_config > > > > > > just in case it is defined in both. > > > > The user file should take precedence in that case. ssh checks that one > > first and stops looking if it finds a host match there. > > Quite and if it finds the wrong setup there, it'll run with it. Exactly, which is why I asked the question. It seems we are both saying the same thing :) Th output shows only the user file being read. -- Neil Bothwick "Self-explanatory": technospeak for "Incomprehensible & undocumented" pgpo88sAtUJV7.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Ssh problem : half-solved
On Monday, 11 March 2019 17:34:20 GMT Neil Bothwick wrote: > On Mon, 11 Mar 2019 16:06:59 +, Mick wrote: > > > It shows that ssh is reading your config file, but not picking up the > > > options for this host. I would expect to see something like > > > > > > debug1: Reading configuration data /home/nelz/.config/ssh > > > debug1: /home/nelz/.config/ssh line N: Applying options for > > > > > > Do you have any other Host stanzas in the config? > > > > Check both config files for conflicts: > > > > /home/purslow/.ssh/config > > /etc/ssh/ssh_config > > > > just in case it is defined in both. > > The user file should take precedence in that case. ssh checks that one > first and stops looking if it finds a host match there. Quite and if it finds the wrong setup there, it'll run with it. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Server fails to boot after update to 4.19.27-r1
On 11.03.19 20:55, J. Roeleveld wrote: On March 10, 2019 1:24:14 PM UTC, Dan Johansson wrote: After updating a server from kernel-4.14.83 to 4.19.27-r1 (same problem with 4.19.23) the server will not boot. Grub starts fine and I can select the new kernel. The kernel starts booting and after mounting "/" and "/usr" (this is a server with a separate /usr") the boot-process hangs. Here are the last few lines displayed before it hangs: Initializing root device... Detected root: /dev/md127 Mounting /dev/md127 as root... Detected fstype: ext4 Using mount fstype: ext4 Using mount opts: -o ro 7.6104971 EXT4-fs (md127): mounted filesystem with ordered data mode. Opts (null) 7.6572671 init (5708) used greatest stack depth: 13280 bytes left Mounting /dev/dm-O as /usr: mount -t ext4 -o noatime,user_xattr,ro /deu/dm-O /newroot/usr 7.6909561 EXT4-fs (dm-0): INFO: recouery required on readonly filesystem 7.6925551 EXT4-fs (dm-0): write access will be enabled diming recouery 7.9169781 EXT4-fs (dm-0): recovery complete 7.9223701 EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: user_xattr 7.9233051 mount (5722) used greatest stack depth, 13000 bytes left /usr already mounted, skipping... Booting (initramfs) sep-usr init: running user requested applet As I said, the 4.14.83 kernel boots without problem with the same configuration. Any suggestions? -- Dan Johansson, *** This message is printed on 100% recycled electrons! *** I updated my servers last weekend and all moved to 4.19.27, 2 use ZFS for the filesystem, several are VMs on top of Xen. None had any issues. The messages you show make me think they are from an initrd, not the actual kernel. I would investigate that first and make sure your initrd is actually updated as well. Did you copy the text? Or did you manage to grab the output somehow? Also, which init system and initrd are you using? -- Joost The text was copied from a screenshot (IPMI-KVM). I am using sys-apps/openrc with sys-fs/eudev and I use genkernel to build the kernel and the initramfs. Yes, for me it also looks like it has to do with /ginit (busybox) or /sbin/init (sys-apps/sysvinit) and not the kernel. I also have a bunch of other servers which all updated fine to 4.19.?? I tried the suggestion from Hasan to run "make synconfig" but that did not change any option in .config. I'll try to rebuild kernel/init/busybox/intel-microcode again next weekend. -- Dan Johansson *** This message is printed on 100% recycled electrons! ***
Re: [gentoo-user] Server fails to boot after update to 4.19.27-r1
On March 10, 2019 1:24:14 PM UTC, Dan Johansson wrote: >After updating a server from kernel-4.14.83 to 4.19.27-r1 (same problem > >with 4.19.23) the server will not boot. > >Grub starts fine and I can select the new kernel. >The kernel starts booting and after mounting "/" and "/usr" (this is a >server with a separate /usr") the boot-process hangs. > >Here are the last few lines displayed before it hangs: > > >> Initializing root device... > >> Detected root: /dev/md127 > >> Mounting /dev/md127 as root... > >> Detected fstype: ext4 > >> Using mount fstype: ext4 > >> Using mount opts: -o ro > 7.6104971 EXT4-fs (md127): mounted filesystem with ordered data >mode. Opts (null) > 7.6572671 init (5708) used greatest stack depth: 13280 bytes left > >> Mounting /dev/dm-O as /usr: mount -t ext4 -o noatime,user_xattr,ro >/deu/dm-O /newroot/usr > 7.6909561 EXT4-fs (dm-0): INFO: recouery required on readonly >filesystem > 7.6925551 EXT4-fs (dm-0): write access will be enabled diming >recouery > 7.9169781 EXT4-fs (dm-0): recovery complete > 7.9223701 EXT4-fs (dm-0): mounted filesystem with ordered data >mode. Opts: user_xattr > 7.9233051 mount (5722) used greatest stack depth, 13000 bytes left > >> /usr already mounted, skipping... > >> Booting (initramfs) >sep-usr init: running user requested applet > > >As I said, the 4.14.83 kernel boots without problem with the same >configuration. > >Any suggestions? >-- >Dan Johansson, >*** >This message is printed on 100% recycled electrons! >*** I updated my servers last weekend and all moved to 4.19.27, 2 use ZFS for the filesystem, several are VMs on top of Xen. None had any issues. The messages you show make me think they are from an initrd, not the actual kernel. I would investigate that first and make sure your initrd is actually updated as well. Did you copy the text? Or did you manage to grab the output somehow? Also, which init system and initrd are you using? -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Ssh problem : half-solved
On Mon, 11 Mar 2019 16:06:59 +, Mick wrote: > > It shows that ssh is reading your config file, but not picking up the > > options for this host. I would expect to see something like > > > > debug1: Reading configuration data /home/nelz/.config/ssh > > debug1: /home/nelz/.config/ssh line N: Applying options for > > > > Do you have any other Host stanzas in the config? > > Check both config files for conflicts: > > /home/purslow/.ssh/config > /etc/ssh/ssh_config > > just in case it is defined in both. The user file should take precedence in that case. ssh checks that one first and stops looking if it finds a host match there. -- Neil Bothwick Linux like wigwam. No windows, no gates, Apache inside. pgp3G625wqLxr.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Ssh problem : half-solved
On Monday, 11 March 2019 13:42:14 GMT Neil Bothwick wrote: > On Mon, 11 Mar 2019 09:08:14 -0400, Philip Webb wrote: > > 190311 Neil Bothwick wrote: > > > Have you run ssh with -v > > > to see what configuration options it is reading from where. > > > Bear in mind that ssh stops at the first matching host definition, > > > so if you have a "host *" in your config, it must be last. > > > > This is what I get : > > 522: ~> ssh -v > > OpenSSH_7.9p1, OpenSSL 1.0.2r 26 Feb 2019 > > debug1: Reading configuration data /home/purslow/.ssh/config > > debug1: Reading configuration data /etc/ssh/ssh_config > > debug1: Connecting to port 22. > > debug1: Connection established. > > debug1: identity file /home/purslow/.ssh/id_rsa type -1 > > debug1: identity file /home/purslow/.ssh/id_rsa-cert type -1 > > debug1: identity file /home/purslow/.ssh/id_dsa type -1 > > debug1: identity file /home/purslow/.ssh/id_dsa-cert type -1 > > debug1: identity file /home/purslow/.ssh/id_ecdsa type -1 > > debug1: identity file /home/purslow/.ssh/id_ecdsa-cert type -1 > > debug1: identity file /home/purslow/.ssh/id_ed25519 type -1 > > debug1: identity file /home/purslow/.ssh/id_ed25519-cert type -1 > > debug1: identity file /home/purslow/.ssh/id_xmss type -1 > > debug1: identity file /home/purslow/.ssh/id_xmss-cert type -1 > > debug1: Local version string SSH-2.0-OpenSSH_7.9 > > debug1: Remote protocol version 2.0, remote software version > > > > OpenSSH_3.7.1p2 debug1: match: OpenSSH_3.7.1p2 pat OpenSSH_3.* compat > > 0x0102 debug1: Authenticating to :22 as 'purslow' > > > > debug1: SSH2_MSG_KEXINIT sent > > debug1: SSH2_MSG_KEXINIT received > > debug1: kex: algorithm: (no match) > > Unable to negotiate with port 22: no matching key exchange > > > > method found. Their offer: > > diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > > > > Is that any help ? > > It shows that ssh is reading your config file, but not picking up the > options for this host. I would expect to see something like > > debug1: Reading configuration data /home/nelz/.config/ssh > debug1: /home/nelz/.config/ssh line N: Applying options for > > Do you have any other Host stanzas in the config? Check both config files for conflicts: /home/purslow/.ssh/config /etc/ssh/ssh_config just in case it is defined in both. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] File collisions while syncing/updateing
On 2019.03.10 22:50, tu...@posteo.de wrote: Hi, I've got this this morning: strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version /usr/lib64/libmxml.so.1.6 * checking 9 files for package collisions * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / ` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at https://bugs.gentoo.org/ unless you report exactly * which two packages install the same file(s). See * https://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how * to solve the problem. And once again, please do NOT file a bug report * unless you have completely understood the above message. * * Detected file collision(s): * * /usr/share/man/man3/mxml.3.bz2 * /usr/include/mxml.h * /usr/lib64/libmxml.so.1.6 * /usr/lib64/pkgconfig/mxml.pc * /usr/lib64/libmxml.so.1 * /usr/lib64/libmxml.so * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * dev-libs/mxml-2.12:0::gentoo * /usr/include/mxml.h * /usr/lib64/libmxml.so * /usr/lib64/libmxml.so.1 * /usr/lib64/libmxml.so.1.6 * /usr/lib64/pkgconfig/mxml.pc * /usr/share/man/man3/mxml.3.bz2 * * Package 'dev-libs/mxml-3.0' NOT merged due to file collisions. If * necessary, refer to your elog messages for the whole content of the * above message. * * The following package has failed to build, install, or execute postinst: * * (dev-libs/mxml-3.0:1/6::gentoo, ebuild scheduled for merge), Log file: * '/var/tmp/portage/dev-libs/mxml-3.0/temp/build.log' Is it ok tp rm /usr/share/man/man3/mxml.3.bz2 /usr/include/mxml.h /usr/lib64/libmxml.so.1.6 /usr/lib64/pkgconfig/mxml.pc /usr/lib64/libmxml.so.1 /usr/lib64/libmxml.so manually prior to reemergeing? Hello Meino, I'd file a bug, as it looks like 2.12 in slot 0 and 3.0 in slot 1 both install some of the same files. It looks like version 3.0 was just added to the tree, so either it doesn't need to be in a separate slot, or else those files need renaming. Deleting and re-emerging would probably work, but if you later remove one of the versions, those files will also be removed, and the remaining version will probably fail due to the missing .so file(s). Jack
Re: [gentoo-user] Ssh problem : half-solved
On Mon, 11 Mar 2019 09:08:14 -0400, Philip Webb wrote: > 190311 Neil Bothwick wrote: > > Have you run ssh with -v > > to see what configuration options it is reading from where. > > Bear in mind that ssh stops at the first matching host definition, > > so if you have a "host *" in your config, it must be last. > > This is what I get : > > 522: ~> ssh -v > OpenSSH_7.9p1, OpenSSL 1.0.2r 26 Feb 2019 > debug1: Reading configuration data /home/purslow/.ssh/config > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Connecting to port 22. > debug1: Connection established. > debug1: identity file /home/purslow/.ssh/id_rsa type -1 > debug1: identity file /home/purslow/.ssh/id_rsa-cert type -1 > debug1: identity file /home/purslow/.ssh/id_dsa type -1 > debug1: identity file /home/purslow/.ssh/id_dsa-cert type -1 > debug1: identity file /home/purslow/.ssh/id_ecdsa type -1 > debug1: identity file /home/purslow/.ssh/id_ecdsa-cert type -1 > debug1: identity file /home/purslow/.ssh/id_ed25519 type -1 > debug1: identity file /home/purslow/.ssh/id_ed25519-cert type -1 > debug1: identity file /home/purslow/.ssh/id_xmss type -1 > debug1: identity file /home/purslow/.ssh/id_xmss-cert type -1 > debug1: Local version string SSH-2.0-OpenSSH_7.9 > debug1: Remote protocol version 2.0, remote software version > OpenSSH_3.7.1p2 debug1: match: OpenSSH_3.7.1p2 pat OpenSSH_3.* compat > 0x0102 debug1: Authenticating to :22 as 'purslow' > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: algorithm: (no match) > Unable to negotiate with port 22: no matching key exchange > method found. Their offer: > diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > > Is that any help ? It shows that ssh is reading your config file, but not picking up the options for this host. I would expect to see something like debug1: Reading configuration data /home/nelz/.config/ssh debug1: /home/nelz/.config/ssh line N: Applying options for Do you have any other Host stanzas in the config? -- Neil Bothwick Make it idiot proof and someone will make a better idiot. pgpuoXCsnatB5.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Ssh problem : half-solved
190311 Neil Bothwick wrote: > Have you run ssh with -v > to see what configuration options it is reading from where. > Bear in mind that ssh stops at the first matching host definition, > so if you have a "host *" in your config, it must be last. This is what I get : 522: ~> ssh -v OpenSSH_7.9p1, OpenSSL 1.0.2r 26 Feb 2019 debug1: Reading configuration data /home/purslow/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to port 22. debug1: Connection established. debug1: identity file /home/purslow/.ssh/id_rsa type -1 debug1: identity file /home/purslow/.ssh/id_rsa-cert type -1 debug1: identity file /home/purslow/.ssh/id_dsa type -1 debug1: identity file /home/purslow/.ssh/id_dsa-cert type -1 debug1: identity file /home/purslow/.ssh/id_ecdsa type -1 debug1: identity file /home/purslow/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/purslow/.ssh/id_ed25519 type -1 debug1: identity file /home/purslow/.ssh/id_ed25519-cert type -1 debug1: identity file /home/purslow/.ssh/id_xmss type -1 debug1: identity file /home/purslow/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.9 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.7.1p2 debug1: match: OpenSSH_3.7.1p2 pat OpenSSH_3.* compat 0x0102 debug1: Authenticating to :22 as 'purslow' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: (no match) Unable to negotiate with port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 Is that any help ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Ssh problem : half-solved
On Mon, 11 Mar 2019 05:23:36 -0400, Philip Webb wrote: > NB> That's how I read it, but it says it appends to the list, > > so this is the last option tried, > > while an earlier one could possibly be triggering the failure. > > With + would be better, but it would be worth trying without. > > I tried both & neither gets Ssh to recognise the config. Have you run ssh with -v to see what configuration options it is reading from where. Bear in mind that ssh stops at the first matching host definition, so if you have a "host *" in your config, it must be last. -- Neil Bothwick When puns are outlawed only outlaws will have puns. pgp97Ullhxm8N.pgp Description: OpenPGP digital signature
[gentoo-user] eix doesn't ignore disabled overlays
Hi, eix-sync and eix-diff reports (newer) packages from disabled overlays (via layman -D ...). How can I tell eix to ignore these? I'm using eix GIT from 2019/03/06. Many thanks for a hint, Helmut
Re: [gentoo-user] Ssh problem : half-solved
On 11/3/19 5:23 pm, Philip Webb wrote: > 190311 Neil Bothwick + Mick wrote: > NB> Try without the +, that works for me here. I have an appliance >> that uses outdated algorithms and this config works for me >> Host 1.2.3.4 >> Ciphers 3des-cbc >> KexAlgorithms diffie-hellman-group1-sha1 >> HostKeyAlgorithms ssh-dss > I tried adding the 2 extra lines to ~/.ssh/config , but no joy. > I didn't reboot, but it's not clear that that would make any difference. > > M> As I understand it the "+" merely adds one more cipher to the collection. >> This is probably safer. If the server has been updated >> and non-legacy key exchange algorithms are now available they can be used. >> Without "+" the directive for the client is exclusive : >> only use this algorithm and nothing else. > That's what the 'man' says. > > NB> That's how I read it, but it says it appends to the list, >> so this is the last option tried, >> while an earlier one could possibly be triggering the failure. >> With + would be better, but it would be worth trying without. > I tried both & neither gets Ssh to recognise the config. > > This is a puzzle : are they any other suggestions ? > This works for me (ancient Cisco ...) rattus ~ # cat ~/.ssh/config Host 192.168.44.1 KexAlgorithms +diffie-hellman-group1-sha1 Host ghost KexAlgorithms +diffie-hellman-group1-sha1 Which file are putting it in? - this is the client side user.
Re: [gentoo-user] Ssh problem : half-solved
190311 Neil Bothwick + Mick wrote: NB> Try without the +, that works for me here. I have an appliance > that uses outdated algorithms and this config works for me > Host 1.2.3.4 > Ciphers 3des-cbc > KexAlgorithms diffie-hellman-group1-sha1 > HostKeyAlgorithms ssh-dss I tried adding the 2 extra lines to ~/.ssh/config , but no joy. I didn't reboot, but it's not clear that that would make any difference. M> As I understand it the "+" merely adds one more cipher to the collection. > This is probably safer. If the server has been updated > and non-legacy key exchange algorithms are now available they can be used. > Without "+" the directive for the client is exclusive : > only use this algorithm and nothing else. That's what the 'man' says. NB> That's how I read it, but it says it appends to the list, > so this is the last option tried, > while an earlier one could possibly be triggering the failure. > With + would be better, but it would be worth trying without. I tried both & neither gets Ssh to recognise the config. This is a puzzle : are they any other suggestions ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Ssh problem : half-solved
On Mon, 11 Mar 2019 08:43:52 +, Mick wrote: > > Try without the +, that works for me here. I have an appliance that > > uses outdated algorithms and this config works for me > > > > Host 1.2.3.4 > > Ciphers 3des-cbc > > KexAlgorithms diffie-hellman-group1-sha1 > > HostKeyAlgorithms ssh-dss > > As I understand it the "+" merely adds one more cipher to the > collection. This is probably safer. If the server has been updated and > non-legacy key exchange algorithms are now available they can be used. > Without "+" the directive for the client is exclusive: only use this > algorithm and nothing else. That's how I read it, but it says it appends to the list, so this is the last option tried, while an earlier one could possibly be triggering the failure. With + would be better, but it would be worth trying without. -- Neil Bothwick "" " """ " "" " """ <-- random quotes pgpum6cP4udJj.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Ssh problem : half-solved
On Monday, 11 March 2019 08:31:33 GMT Neil Bothwick wrote: > On Mon, 11 Mar 2019 01:41:19 -0400, Philip Webb wrote: > > That forum contains a solution : > > ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 123.123.123.123 > > > > That gets me thro' & I can do my work there. > > > > > Enable legacy and possible less secure key exchange formats and > > > ciphers only per server and not globally > > > and if possible upgrade the SSH server version. > > > > However, I've tried to insert an instruction in config files, > > but nothing changes after a reboot. > > > > I've tried adding to ~/.ssh/config & /etc/ssh/ssh_config : > > Host 128.100.160.1 > > > > KexAlgorithms +diffie-hellman-group1-sha1 > > > > That is what seems to be required by 'man 5 ssh_config'. > > Try without the +, that works for me here. I have an appliance that uses > outdated algorithms and this config works for me > > Host 1.2.3.4 > Ciphers 3des-cbc > KexAlgorithms diffie-hellman-group1-sha1 > HostKeyAlgorithms ssh-dss As I understand it the "+" merely adds one more cipher to the collection. This is probably safer. If the server has been updated and non-legacy key exchange algorithms are now available they can be used. Without "+" the directive for the client is exclusive: only use this algorithm and nothing else. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Ssh problem : half-solved
On Mon, 11 Mar 2019 01:41:19 -0400, Philip Webb wrote: > That forum contains a solution : > > ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 123.123.123.123 > > That gets me thro' & I can do my work there. > > > Enable legacy and possible less secure key exchange formats and > > ciphers only per server and not globally > > and if possible upgrade the SSH server version. > > However, I've tried to insert an instruction in config files, > but nothing changes after a reboot. > I've tried adding to ~/.ssh/config & /etc/ssh/ssh_config : > > Host 128.100.160.1 > KexAlgorithms +diffie-hellman-group1-sha1 > > That is what seems to be required by 'man 5 ssh_config'. Try without the +, that works for me here. I have an appliance that uses outdated algorithms and this config works for me Host 1.2.3.4 Ciphers 3des-cbc KexAlgorithms diffie-hellman-group1-sha1 HostKeyAlgorithms ssh-dss -- Neil Bothwick New sig wanted good price paid. pgpcfUAMujEUC.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Ssh problem : half-solved
On Monday, 11 March 2019 05:41:19 GMT Philip Webb wrote: [snip ...] > However, I've tried to insert an instruction in config files, > but nothing changes after a reboot. > I've tried adding to ~/.ssh/config & /etc/ssh/ssh_config : > > Host 128.100.160.1 > KexAlgorithms +diffie-hellman-group1-sha1 > > That is what seems to be required by 'man 5 ssh_config'. > > Can anyone suggest what + where to tell Ssh to do it every time ? You probably have more than one User and identity file and you could define them both in .ssh/config to make sure the correct user is invoked, without having to add it to the CLI: Host 128.100.160.1 User my_remote_ssh_user IdentityFile /home//.ssh/id_rsa KexAlgorithms +diffie-hellman-group1-sha1 -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] start ntpdate after network....
On Sun, 10 Mar 2019 18:55:29 -0400, Rich Freeman wrote: > > Mar 11 00:33:37 localhost ntpdate[4553]: Exiting, name server cannot > > be used: Temporary failure in name resolution (-3)11 Mar 00:33:37 > > ntpdate[4553]: name server cannot be used: Temporary failure in name > > resolution (-3) > > Ok, you didn't mention what you're using for a network manager. How > is the network interface being configured in the first place? There > are several ways that it is commonly done. > > Also, what are you using for DNS? In particular, are you running a > local DNS server, or are you relying on a network-supplied DNS server? > How is /etc/resolv.conf being created (likely by the network manager, > but maybe it is being done in another way). Also, where is the NTP server? On the local network or external? > ntpdate by default depends on network-online.target and not on > nss-lookup.target, which can sometimes lead to issues if you're > running a DNS server that isn't online when the network is online > (such as a local server). The definitions of when a network is actually online are variable, see https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ You may need to add NetworkManager-wait-online.service or systemd-networkd-wait-online.service to the dependencies for ntpdate, which is possibly why Rich is asking how you manage your network. I don't use ntpdate here but systemd-timesyncd.service instead, which seems to handle this better. -- Neil Bothwick An atheist is someone who feels he has no invisible means of support. pgpGsXVUnreSU.pgp Description: OpenPGP digital signature
