Re: [gentoo-user] Ssh problem : half-solved

[Philip Webb]

190310 Nils Freydank wrote:
> Am Sonntag, 10. März 2019, 08:25:54 CET schrieb Philip Webb:
>> I updated Ssh yesterday :
>> [...]
>>   ssh x.y.z
>>   Unable to negotiate with 128.100.160.1 port 22: no matching key
>> exchange method found. Their offer:
>> diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> ssh tells you straight forward what the issue is:
> Within the key exchange at the begin of the communication
> there was no way to establish a connection between server and client,
> probably because the client has a more secure setup than the server.
> This happens mostly due to old ssh versions serverside.

Yes, they mb a bit slow to upgrade.

> You can find solutions pretty fast
> by just searching for "Their offer: ",
> e.g. https://unix.stackexchange.com/questions/340844/
> how-to-enable-diffie-hellman-group1-sha1-key-exchange-on-debian-8-0

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'.

Can anyone suggest what + where to tell Ssh to do it every time ?

>> 'x.y.z' disguises the site's URL, which doesn't seem to be a problem.
> That is indeed perfectly fine;
> you might want to hide the IP address in the future as well ;-)

Indeed (red face) : it was at the end of my day.
No point in trying to hide it now (wry smile).

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

[gentoo-user] File collisions while syncing/updateing

[tuxic]

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?

Cheers!
Meino

Re: [gentoo-user] start ntpdate after network....

[Manuel McLure]

On Sun, Mar 10, 2019 at 3:41 PM Tamer Higazi  wrote:

> Mar 11 00:33:36 localhost systemd[1]: Starting Set time via NTP using
> ntpdate...
> 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)
> Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Main process
> exited, code=exited, status=1/FAILURE
> Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Failed with
> result 'exit-code'.
> Mar 11 00:33:37 localhost systemd[1]: Failed to start Set time via NTP
> using ntpdate.
>

Do you have IPV6 enabled at all on your network? I have seen problems in
the past where the DHCP client (dhcpcd) would return as soon as it got an
IPV6 address so processes that depended on an IPV4 address would fail to
start - in my case I've seen it both with MySQL and with NFS mounts.

The solution (if you're using dhcpcd as your DHCP client) is to add either

waitip 4

or

waitip 4 6

to the end of your /etc/dhcpcd.conf file.

-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft

Re: [gentoo-user] start ntpdate after network....

[Rich Freeman]

On Sun, Mar 10, 2019 at 6:40 PM Tamer Higazi  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).

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).

-- 
Rich

Re: [gentoo-user] start ntpdate after network....

[Tamer Higazi]

Hi Rich,

Thank you for your response.

I am using the units that are supplied with gentoo
I just restarted my machine and I get this output "systemctl status 
ntpdate":



* ntpdate.service - Set time via NTP using ntpdate
   Loaded: loaded (/lib/systemd/system/ntpdate.service; enabled; vendor 
preset: disabled)

  Drop-In: /etc/systemd/system/ntpdate.service.d
   `-00gentoo.conf
   Active: failed (Result: exit-code) since Mon 2019-03-11 00:33:37 
CET; 2min 30s ago
  Process: 4553 ExecStart=/usr/sbin/ntpdate -b -u $SERVER (code=exited, 
status=1/FAILURE)

 Main PID: 4553 (code=exited, status=1/FAILURE)

Mar 11 00:33:36 localhost systemd[1]: Starting Set time via NTP using 
ntpdate...
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)
Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Main process 
exited, code=exited, status=1/FAILURE
Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Failed with 
result 'exit-code'.
Mar 11 00:33:37 localhost systemd[1]: Failed to start Set time via NTP 
using ntpdate.


and for the output looks like this:

-- Logs begin at Tue 2019-02-19 08:58:02 CET, end at Mon 2019-03-11 
00:34:43 CET. --
Mar 11 00:33:36 localhost systemd[1]: Starting Set time via NTP using 
ntpdate...
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)
Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Main process 
exited, code=exited, status=1/FAILURE
Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Failed with 
result 'exit-code'.
Mar 11 00:33:37 localhost systemd[1]: Failed to start Set time via NTP 
using ntpdate.


If i start by hand, after the system is up with "systemctl start ntpdate":

* ntpdate.service - Set time via NTP using ntpdate
   Loaded: loaded (/lib/systemd/system/ntpdate.service; enabled; vendor 
preset: disabled)

  Drop-In: /etc/systemd/system/ntpdate.service.d
   `-00gentoo.conf
   Active: active (exited) since Sun 2019-03-10 23:38:36 CET; 2s ago
  Process: 5093 ExecStart=/usr/sbin/ntpdate -b -u $SERVER (code=exited, 
status=0/SUCCESS)

 Main PID: 5093 (code=exited, status=0/SUCCESS)

Mar 11 00:37:59 localhost systemd[1]: Starting Set time via NTP using 
ntpdate...
Mar 10 23:38:36 localhost ntpdate[5093]: 10 Mar 23:38:36 ntpdate[5093]: 
step time server 162.23.41.10 offset -3573.367681 sec
Mar 10 23:38:36 localhost systemd[1]: Started Set time via NTP using 
ntpdate.


also the result here looks different ( journalctl -ab -u ntpdate) by 
executing manually:


Mar 10 23:38:36 localhost ntpdate[5093]: 10 Mar 23:38:36 ntpdate[5093]: 
step time server 162.23.41.10 offset -3573.367681 sec
Mar 10 23:38:36 localhost systemd[1]: Started Set time via NTP using 
ntpdate.


then everything looks fine...


Any ideas ?


best, Tamer

On 10.03.19 22:36, Rich Freeman wrote:

On Sun, Mar 10, 2019 at 5:16 PM Tamer Higazi  wrote:

I have my gentoo system running with systemd.

I figured out that ntpdate is getting started before network is up.
I am not yet very familiar with systemd.

Can somebody of you tell me how to fix that, that "ntpdate" is started
the moment network devices are up ?


How is ntpdate being run?  If you're using the supplied unit then it
should default to starting after network-online.target, which if
you're using a network manager started by systemd should delay it
until the network is running.

Now, if you're starting ntpdate in some other way then you'd need to
make sure that the network is online, and if you're starting the
network without using a supplied systemd unit then you'd need to make
sure systemd is aware of when it is up.

Basically, it should just work for the most part if you're using the
supplied units, but you don't mention much about your configuration
and Gentoo users do have a tendency to roll up their sleeves and do
things in scripts/etc.

The output of something like "systemctl status ntpdate" or "journalctl
-ab -u ntpdate" might be helpful.  I'm not sure how you're configuring
your network (networkd, etc)?  That would also be useful to know, as
well as the journal log for the associated units.

Systemd is highly dependency-driven and parallel, so issues like this
are mostly the result of failing to declare a dependency somewhere
(either on the network side or the ntp side).  If you're using openrc
in parallel mode you need to do the same, and again that should be
taken care of out of the box if you're using the supplied services,
but if you roll your own you also have to be careful.

Re: [gentoo-user] Server fails to boot after update to 4.19.27-r1

[Hasan Ç .]

I just upgraded to 4.19.27-r1 and there wasn't any issue.I think issue is
related to your kernel compile procedure.

If you used genkernel i don't know how it handles things.

If you compiled kernel manually my best guess for troubleshooting for non
EFI system-->

 your initramfs (regenerate)
 your kernel .config
 /etc/default/grub settings  /boot/grub/grub.cfg.
 microcode cpio for any breaks

 start from scratch ---

make mrproper
make menuconfig --> save & exit <--
make syncconfig  --> need for 4.19. This will sync your old kernel config
but i always prefer to get a fine tuned one from my trusted sources if
kernel upgrade is major <--

make
make modules_install
make install
dracut --force --regenerate-all
grub-mkconfig -o /boot/grub/grub.cfg

10 Mar 2019 Pzr 4:24 PM tarihinde Dan Johansson  şunu
yazdı:

> 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!
> ***
>
>

Re: [gentoo-user] start ntpdate after network....

[Rich Freeman]

On Sun, Mar 10, 2019 at 5:16 PM Tamer Higazi  wrote:
>
> I have my gentoo system running with systemd.
>
> I figured out that ntpdate is getting started before network is up.
> I am not yet very familiar with systemd.
>
> Can somebody of you tell me how to fix that, that "ntpdate" is started
> the moment network devices are up ?
>

How is ntpdate being run?  If you're using the supplied unit then it
should default to starting after network-online.target, which if
you're using a network manager started by systemd should delay it
until the network is running.

Now, if you're starting ntpdate in some other way then you'd need to
make sure that the network is online, and if you're starting the
network without using a supplied systemd unit then you'd need to make
sure systemd is aware of when it is up.

Basically, it should just work for the most part if you're using the
supplied units, but you don't mention much about your configuration
and Gentoo users do have a tendency to roll up their sleeves and do
things in scripts/etc.

The output of something like "systemctl status ntpdate" or "journalctl
-ab -u ntpdate" might be helpful.  I'm not sure how you're configuring
your network (networkd, etc)?  That would also be useful to know, as
well as the journal log for the associated units.

Systemd is highly dependency-driven and parallel, so issues like this
are mostly the result of failing to declare a dependency somewhere
(either on the network side or the ntp side).  If you're using openrc
in parallel mode you need to do the same, and again that should be
taken care of out of the box if you're using the supplied services,
but if you roll your own you also have to be careful.

-- 
Rich

[gentoo-user] start ntpdate after network....

[Tamer Higazi]

Hi people,

I have my gentoo system running with systemd.

I figured out that ntpdate is getting started before network is up.
I am not yet very familiar with systemd.

Can somebody of you tell me how to fix that, that "ntpdate" is started 
the moment network devices are up ?


for any response and ideas, thank you!


best, Tamer

Re: [gentoo-user] Re: Help with emerge error msg

[allan gottlieb]

On Sun, Mar 10 2019, Nikos Chantziaras wrote:

> On 10/03/2019 00:24, allan gottlieb wrote:
>>The following REQUIRED_USE flag constraints are unsatisfied:
>>  inspector? ( icu )
>>
>>The above constraints are a subset of the following complete expression:
>>  python_targets_python2_7 inspector? ( icu ssl ) npm? ( ssl )
>>
>> This seems more serious than a simple request to add the icu USE flag to
>> nodejs.
> That's actually exactly what that means. The ebuild states that if
> "inspector" is set, then you also need to set "icu" and "ssl".

Thank you corbin and nikos.

I guess I was led astray by the reference to python_targets* and thought
something more serious was being asked.

The build is now underway.

thanks again,
allan

[gentoo-user] Server fails to boot after update to 4.19.27-r1

[Dan Johansson]

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!
***

Re: [gentoo-user] Ssh problem

[Nils Freydank]

Hi Philip,

Am Sonntag, 10. März 2019, 08:25:54 CET schrieb Philip Webb:
> I updated Ssh yesterday :
> [...]
>   ssh x.y.z
>   Unable to negotiate with 128.100.160.1 port 22: no matching key
> exchange method found. Their offer:
> diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
ssh tells you straight forward what the issue is: Within the key exchange
at the begin of the communication there was no way to establish a 
connection between the server and the client, probably because the client 
has a more secure setup than the server. This happens mostly due to old ssh 
versions serverside.

You can find solutions pretty fast by just searching for "Their offer: ", e.g. https://unix.stackexchange.com/questions/340844/
how-to-enable-diffie-hellman-group1-sha1-key-exchange-on-debian-8-0

(Please 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.)

> 'x.y.z' disguises the site's URL, which doesn't seem to be a problem.
That is indeed perfectly fine; you might want to hide the IP address in the 
future aswell ;-)


Greetings,
Nils

-- 
GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B'
Nils Freydank

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] [SOLVED] layman config file setup?

[Mick]

On Sunday, 10 March 2019 01:01:47 GMT Walter Dnes wrote:
>   My apologies for wasting everybody's time.  

No problem, posting and thinking it through is part of troubleshooting!  ;-)

We've all been there.


>   I think that I
> misinterpreted https://wiki.gentoo.org/wiki/Layman and did a mix of the
> config method for both version 2.1.0 and later as well as versions prior
> to 2.1.0  Needless to say, the system was badly confused.
> 
>   I removed all overlays, unmerged layman, removed all directories/files
> related to layman, and the entry in make.conf.  Then I did a fresh
> install...
> 
> emerge layman
> layman -S
> layman -a palemoon
> 
>   It works fine now.

Retracing one's steps can help identifying mistakes, but the thing with layman 
is there were a number of overlapping and confusing changes.  Given layman is 
a means to an end, rather than a destination, absorbing oneself in all the 
config changes is more of an obstacle than part of an enjoyable experience. :p

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: Ssh problem

[Nikos Chantziaras]

On 10/03/2019 09:25, Philip Webb wrote:

no matching key exchange method found. Their offer: 
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1


First hit on a web search:

https://unix.stackexchange.com/questions/340844/how-to-enable-diffie-hellman-group1-sha1-key-exchange-on-debian-8-0