Re: [gentoo-user] Re: emerging squid indefinitely

[Alan McKinnon]

On 25/11/2015 13:30, lee wrote:
> walt  writes:
> 
>> On Tue, 24 Nov 2015 23:39:01 +0100
>> lee  wrote:
>>
>>>
>>> ...
>>
>>  
>>> Well, ok, the file is still locked.
>>>
>>> 'group-' looks like a backup, and 'group.lock' contains 10563, which
>>> is the pid of groupadd.  I'd think that's ok.
>>>
>>> So what all does it take to create a system group?  I suppose I could
>>> kill groupadd and the emerging might go on, though I wonder what the
>>> problem might be and if something else besides making an entry to
>>> /etc/group needs to be done.  What might require an indefinite delay
>>> here?
>>
>> Any unusual network activity?  (DNS lookups that shouldn't be
>> happening, etc.) 
> 
> There's nothing suspicious in the firewall log and no unexpected DNS
> queries.

Ignore DNS, it has absolutely nothing to do with creating a group. A
common human trait in dealing with problems with unknown causes is to
start investigating all manner of weird and entirely unrelated things.

I suppose theoretically you might discover some interaction between them
in truly bizarre conditions but that's never something you entertain.
Much like you don't check the health of your dog when investigating a
flat type (protests about dogs biting tyres and getting stomach upsets
notwithstanding)

> The emerge before this one was apache, which I suppose also creates a
> system group, and that worked just fine.
> 
> I'll probably reboot today or tomorrow because I need to have a
> differently configured kernel running to be able to do some traffic
> shaping.  If I do that, I'll probably just kill groupadd and see if the
> merging continues.

The group is already created so kill groupadd. One of three things will
happen:

1. the emerge will continue. Do nothing
2. The emerge will fail with a groupadd error. Restart the emerge
3. Nothing will change. Kill the emerge and restart it

If the lockfile persists after killing groupadd, delete it.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Chrony-2.2 failing

[Alan McKinnon]

On 24/11/2015 17:24, Peter Humphrey wrote:
> On Saturday 21 November 2015 09:59:18 I wrote:
> 
>> I think I'll follow Alan's suggestion and head upstream.
> 
> After some discussion with Miroslav Lichvar I've found a chrony.conf that 
> works for me on my 32-bit 2-core Atom. This is it:
> 
> pool pool.ntp.org iburst
> server ntp0.zen.co.uk iburst
> server ntp1.zen.co.uk iburst
> driftfile /var/lib/chrony/drift
> makestep 1.0 3
> allow 192.168.1/24
> mailonchange prh@serv.prhnet 0.5
> rtcfile /var/lib/chrony/rtc
> rtconutc
> 
> The installation-default file causes the start-stop-daemon to catch an 
> unexpected interrupt and report an error, even though the chronyd process 
> continues to run.
> 
> Any time I run 'strace -ff -o/tmp/chronyd.strace /etc/init.d/chronyd start' 
> the init process runs normally and I'm left with scores of trace files, none 
> of which help because the stray interrupt wasn't detected.
> 
> So I'm left with a setup that works for me but leaves what looks (to me) 
> like a timing problem unsolved.
> 
> I'll report back if I hear any more.
> 



Ugh, don't you just hate issues like that? The problem with "solutions"
like start-stop-daemon is they have to deal with whatever the daemon
feels like returning (an infinite number of permutations), so support
for daemon is never complete.

Regardless of what one thinks of systemd, this is one of the things it
set out to deal with. There's only one way to start something, and it
behaves one way, making behaviour considerably more predictable.

[ A bit of a rant I know, but I'm still smarting from years of rancid
and Cisco logins - basically the same kind of problem you are having on
a much larger scale...]


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] https://wiki.gentoo.org/wiki/Traffic_shaping

[lee]

Alan McKinnon  writes:

> On 23/11/2015 22:31, lee wrote:
>> Todd Goodman  writes:
>> 
>>> * Peter Humphrey  [151123 07:15]:
 On Monday 23 November 2015 12:11:36 Peter Humphrey wrote:
> On Monday 23 November 2015 12:29:42 lee wrote:
>> Neil Bothwick  writes:
>>> Grepping .config proves nothing. If a requirement of the option is not
>>> set, the option may not appear in .config. The only reliable test is
>>> the
>>> search facility in make *config.
>>
>> Search facility?
>>
>> I only use menuconfig and often times, it's difficult to find a
>> particular option I'm looking for.
>
> Touch the / key, then enter the option name minus the CONFIG_ prefix. Case
> is not sensitive.

 I forgot to add that if more than one result is returned, they're 
 numbered. 
 Then if you hit the number key of the one you want, you go straight to it.
>>>
>>> And when you exit from reading that selection you get back to the
>>> results list.
>>>
>>> It's pretty slick and sure beats looking where I "think" it should be or
>>> grepping KConfig files.
>> 
>> Wow, that might save me a lot of time :)
>> 
>> And qdisc is extremely well hidden, I'd never have found that.  It
>> doesn't show up unless other options are enabled:  You have to know
>> exactly what you want to enable before even knowing that it's there.
>> 
>> How are we supposed to be able to configure a kernel when we can't even
>> see the available options anymore?
>> 
>
>
> By using a tool that *does* show you the options and how to make them
> available.

Which tool is that?

> The kernel devs have no desire to hold anyone's hand; they assume
> (correctly IMNSHO) that anyone configuring a kernel knows what they are
> doing and knows the tools to use. With that approach, sometimes the user
> runs into things they can't find, and it's an acceptable price to pay.

Assuming that when someone wants to do something they already know what
they are doing and not allowing them to learn by hiding what there is to
know leads to nobody being able to do anything.

Ask around: How many people do know exactly what they are doing when
they are configuring a kernel?  You only need to find one who doesn't to
prove the supposed assumption of the kernel developers wrong.  And I
never really knew what I was doing when I configured a kernel.  Do you?
Who does?

[gentoo-user] Re: emerging squid indefinitely

[walt]

On Wed, 25 Nov 2015 18:53:50 +0200
Alan McKinnon  wrote:

> On 25/11/2015 13:30, lee wrote:
> > walt  writes:
> >   
> >> On Tue, 24 Nov 2015 23:39:01 +0100
> >> lee  wrote:
> >>  
> >>>
> >>> ...  
> >>

> >>
> >> Any unusual network activity?  (DNS lookups that shouldn't be
> >> happening, etc.)   
> > 
> > There's nothing suspicious in the firewall log and no unexpected DNS
> > queries.  
> 
> Ignore DNS, it has absolutely nothing to do with creating a group. A
> common human trait in dealing with problems with unknown causes is to
> start investigating all manner of weird and entirely unrelated things.

And Happy Thanksgiving to you, grouchy old fart living somewhere south
of the equator where no one celebrates Thanksgiving :)

IIRC I learned about DNS queries causing delays directly from you.

Well, maybe it was some other old fart on this list.

Re: [gentoo-user] Weird "df" output

[Rich Freeman]

On Wed, Nov 25, 2015 at 5:30 PM, Jc García  wrote:
> 2015-11-25 16:10 GMT-06:00  :
>
>> /dev/sda7.  Here's the relevant portion of /etc/fstab...
> ...
>
>> /home/bindmounts/opt/optauto bind   0 0
>
> Why not use regular partiontions instand of bindmounts, you are just
> doing weird stuff seems to me.
>

Then all your free space gets fragmented across a dozen different
filesystems and you end up micromanaging everything.

I use one filesystem for root, and another filesystem for everything
else.  I mostly use symlinks, but at times Gentoo has been picky about
symlinks so in some cases I've used bind mounts instead.  When my root
was really tiny and almost everything was elsewhere I had a ton of
bind mounts.  Now that all the places portage touches are on root I
don't have to deal with that as much.

I think the df behavior above is somewhat normal when you have bind mounts.

-- 
Rich

Re: [gentoo-user] Weird "df" output

[Jc García]

2015-11-25 16:10 GMT-06:00  :

> /dev/sda7.  Here's the relevant portion of /etc/fstab...
...

> /home/bindmounts/opt/optauto bind   0 0

Why not use regular partiontions instand of bindmounts, you are just
doing weird stuff seems to me.

Re: [gentoo-user] Weird "df" output

[lee]

waltd...@waltdnes.org writes:

>   I'll admit that my system setup is a bit unusual.  A long time ago, in
> a place far away, hard drives were small, compared to today's standards.
> The usual unix practice of multiple seprate partitions was not feasable
> for me, but I did want to keep root on its own partition.  So I

I remember partitioning a 60MB hard disk.  That was a really huge disk.
What's not feasible with partitioning a gigantic 500MB disk?

> compromised with a small / partition, with empty /home, /opt, /var,
> /usr, and /tmp directories.  Their real equivalents are bind-mounted
> from a much larger partition.

Why don't you just mount the large partition somewhere under /mnt and
create symlinks to the directories that are missing on the small
partition?

You might need /sbin and/or /bin on the small partition itself to be
able to mount anything at all.

Or, why don't you copy the system to the disk that has the large
partition and retire the 500MB disk?  That would reduce power
consumption and increase reliability by having less disks in use and by
making it more unlikely to mess up anything due to excessive
partitioning.


Not that I would do any of this.  Disks always come at least in pairs
because redundancy is required.  And since this is only one of your
machines, you could even run it diskless.

Re: [gentoo-user] Re: emerging squid indefinitely

[lee]

Alan McKinnon  writes:

> On 25/11/2015 13:30, lee wrote:
>> walt  writes:
>> 
>>> On Tue, 24 Nov 2015 23:39:01 +0100
>>> lee  wrote:
>>>

 ...
>>>
>>>  
 Well, ok, the file is still locked.

 'group-' looks like a backup, and 'group.lock' contains 10563, which
 is the pid of groupadd.  I'd think that's ok.

 So what all does it take to create a system group?  I suppose I could
 kill groupadd and the emerging might go on, though I wonder what the
 problem might be and if something else besides making an entry to
 /etc/group needs to be done.  What might require an indefinite delay
 here?
>>>
> [...]
>> I'll probably reboot today or tomorrow because I need to have a
>> differently configured kernel running to be able to do some traffic
>> shaping.  If I do that, I'll probably just kill groupadd and see if the
>> merging continues.
>
> The group is already created so kill groupadd. One of three things will
> happen:
>
> 1. the emerge will continue. Do nothing
> 2. The emerge will fail with a groupadd error. Restart the emerge
> 3. Nothing will change. Kill the emerge and restart it
>
> If the lockfile persists after killing groupadd, delete it.

Well, yes ... I just would like to know what the problem might be.

[gentoo-user] Re: Weird "df" output

[Jonathan Callen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/25/2015 05:10 PM, waltd...@waltdnes.org wrote:
>   I'll admit that my system setup is a bit unusual.  A long time ago, in
> a place far away, hard drives were small, compared to today's standards.
> The usual unix practice of multiple seprate partitions was not feasable
> for me, but I did want to keep root on its own partition.  So I
> compromised with a small / partition, with empty /home, /opt, /var,
> /usr, and /tmp directories.  Their real equivalents are bind-mounted
> from a much larger partition.  I just re-did my oldest machine.  It has
> a primary partition 1, which covers the entire hard drive.  The /
> partion on /dev/sda5 is approximately 500 megabytes (YES!).  There's a
> 3.8 gigabyte swap partion /dev/sda6, and the rest of the drive is
> /dev/sda7.  Here's the relevant portion of /etc/fstab...
>
> /dev/sda5   /   ext2 noatime,async  0 1
> /dev/sda7   /home   ext3 noatime,async  0 1
> /home/bindmounts/opt/optauto bind   0 0
> /home/bindmounts/var/varauto bind   0 0
> /home/bindmounts/usr/usrauto bind   0 0
> /home/bindmounts/tmp/tmpauto bind   0 0
> /dev/sda6   noneswap sw 0 0
>
> ...and the output from "df"...
>
> Filesystem 1K-blocks  Used Available Use% Mounted on
> /dev/root 495944 49416420928  11% /
> devtmpfs   10240 0 10240   0% /dev
> tmpfs 310080   356309724   1% /run
> shm  1550384 0   1550384   0% /dev/shm
> cgroup_root10240 0 10240   0% /sys/fs/cgroup
> /dev/sda7  476205120 292365556 159643008  65% /opt
>
> ...showing /dev/sda7 mounted on /opt !?!?  mc (Midnight Commander) shows
> 152 of 454 gigabytes free on all of /home, /opt, /var, /usr, and /tmp,
> which is correct, since they're all really bindmounts from /dev/sda7.
> The / partition (/dev/sda5) has 411 of 484 megabytes free.  The machine
> works OK, but the "df" output is a head-scratcher.  I've re-booted a
> couple of times, with no change.
>

df reads /proc/self/mountinfo to get the list of mount points. This file
will probably look something like this for your system (exact numbers,
order, and contents may vary):

1 0 4:0 / / rw,noatime,async - ext2 /dev/root rw
2 1 0:1 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
3 1 0:2 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
4 1 0:3 / /dev rw,nosuid - devtmpfs devtmpfs rw,size=10240k,mode=755
5 1 0:4 / /run rw,nosuid,nodev - tmpfs tmpfs rw,size=310080k,mode=755
5 4 0:5 / /dev/shm rw,nosuid,nodev - shm tmpfs rw
6 4 0:6 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts 
rw,gid=5,mode=620,ptmxmode=000
7 2 0:7 / /sys/fs/cgroup rw,nosuid,nodev,noexec - tmpfs cgroup_root 
rw,size=1024k,mode=755
8 1 8:7 / /home rw,noatime,async - ext3 /dev/sda7 rw,data=ordered
9 1 8:7 /bindmounts/opt /opt rw,noatime,async - ext3 /dev/sda7 rw,data=ordered
10 1 8:7 /bindmounts/var /var rw,noatime,async - ext3 /dev/sda7 rw,data=ordered
11 1 8:7 /bindmounts/usr /usr rw,noatime,async - ext3 /dev/sda7 rw,data=ordered
12 1 8:7 /bindmounts/tmp /tmp rw,noatime,async - ext3 /dev/sda7 rw,data=ordered

Note that all the bind mounts show up with the exact same device name as
the original mount they were bound off of. In the interest of not
showing duplicate information, df will only show the mountpoint that has
the shortest path, using the first of those that have the same length
path. As "/opt" is shorter than "/home", that is the mountpoint df uses
as its display name.

The fields in the file are as follows:

1: mount number
2: parent mount number
3: device major:minor mounted (0:x for filesystems not backed by a
block device)
4: path within filesystem mounted
5: mountpoint
6: per-mount options (may differ with multiple mounts of same
filesystem)
(any number of optional per-mount flags may follow, terminated with...)
7: the exact string "-"
8: filesystem type
9: filesystem device name (or string passed to mount(2) for virtual
filesystems)
10: per-device options (always the same for multiple mounts of same
device)
(any number of optional per-device flags may follow)

Note that on Linux, df now prefers to use /proc/self/mountinfo
*instead* of the old /etc/mtab file that (usually) gets written when
mount is called.

- -- 
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWVk7iAAoJEEIQbvYRB3mg0pkP/2q3QsRDFFNZShv/tH5W6zkO
tDk9GX/fMa6R+DyY151ZHiMNOqb/DZRupFudOHJOAIP8oUHAJxOdDg8NXrLFsbcs
8iNEKfLLQq2VrTPpdOoFZcNu2I8vVhc9F08IFTo2wqS8CXPzu7qBH/e5cpDsq43S
W0QKxEptgaGoYSdy3PLRoXcz8kUHYC/tbnJo33tZFu9iRss2WF1EAw3jOtZh0SNO
IoZmowzVNml9WQr7SKVGx/8lrOqzUfahb+vBRnpGi+B+VSLrhbAnkWLtxz7Kv5ws
OyuCuN2DCkyDKFjF/KxP/vp4Uyx6xkqX2KEfG0FcctMD17eHMJFscXb6RMNKQhUu
LNgqfn3Tkk555GC2lP9ZWlT08BqijQ8Tg7d36iCcwJcb5qQpCsszH2j1uHq+4pzi

Re: [gentoo-user] Re: Weird "df" output

[waltdnes]

On Wed, Nov 25, 2015 at 07:15:44PM -0500, Jonathan Callen wrote

> Note that all the bind mounts show up with the exact same device name as
> the original mount they were bound off of. In the interest of not
> showing duplicate information, df will only show the mountpoint that has
> the shortest path, using the first of those that have the same length
> path. As "/opt" is shorter than "/home", that is the mountpoint df uses
> as its display name.

  Thanks for the info.  I'm not that knowledgable to be able to figure
out that it was a df "feature", rather than a problem with my system.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Weird "df" output

[Mark David Dumlao]

On Nov 26, 2015 08:30, "lee"  wrote:
> waltd...@waltdnes.org writes:
> > compromised with a small / partition, with empty /home, /opt, /var,
> > /usr, and /tmp directories.  Their real equivalents are bind-mounted
> > from a much larger partition.
>
> Why don't you just mount the large partition somewhere under /mnt and
> create symlinks to the directories that are missing on the small
> partition?

wrt space, that doesn't really change things.
wrt symlinks, some legacy tools, and regular unix tools have a completely
different behavior when traversing symlinks as opposed to regular
directories, which bindmounts emulate. although in practice i imagine it
wont affect him.

youre really just proposing a different way to do the same thing albeit his
approach is more stable.

> Or, why don't you copy the system to the disk that has the large
> partition and retire the 500MB disk?  That would reduce power
> consumption and increase reliability by having less disks in use and by
> making it more unlikely to mess up anything due to excessive
> partitioning.

its not 2 disks, its one disk and with partitions. at any rate his approach
is valid.

[gentoo-user] dcron problem on new install

[waltdnes]

  I'm getting a bunch of messages like...

> Subject: cron for user root root[ ! -x /etc/cron.hourly/0anacron ] && 
> { test -x /usr/sbin/run-crons && /usr/sbin/run-crons ; }
>
> /bin/sh: root: command not found

/bin/sh does exist...

[d531][waltdnes][~] ll /bin/sh
lrwxrwxrwx 1 root root 4 Nov 24 12:10 /bin/sh -> bash

/etc/  cron.hourly  cron.weekly  cron.monthly   are empty except for a
dummy file .keep_sys-process_cronbase-0

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] openssh-7.1_p1-r2 won't allow "nxserver" to connect [continued]

[Neil Bothwick]

On Wed, 25 Nov 2015 11:58:47 -0700, the...@sys-concept.com wrote:

> I had the same problem.
> openssh-7.xxx (screwed up) by disabling ssh-dss key (that is what
> nxserver is using).

That's not what the error message you posted said.

> Trying to enable the "ssh-dss" via sshd_config does not work!

Which you would expect if that was not the problem. From memory, I think
your problem was caused by password logins as root being disabled. That
was another change for 7.0 and my only comment on that is "why the hell
did they wait until version 7.0 before getting rid of such and insecure
default?".


-- 
Neil Bothwick

Age and treachery will always overcome youth and skill.


pgpgeoNTsMrwi.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] openssh-7.1_p1-r2 won't allow "nxserver" to connect [continued]

[thelma]

On 11/25/2015 12:31 PM, Neil Bothwick wrote:
> On Wed, 25 Nov 2015 11:58:47 -0700, the...@sys-concept.com wrote:
> 
>> I had the same problem.
>> openssh-7.xxx (screwed up) by disabling ssh-dss key (that is what
>> nxserver is using).
> 
> That's not what the error message you posted said.
> 
>> Trying to enable the "ssh-dss" via sshd_config does not work!
> 
> Which you would expect if that was not the problem. From memory, I think
> your problem was caused by password logins as root being disabled. That
> was another change for 7.0 and my only comment on that is "why the hell
> did they wait until version 7.0 before getting rid of such and insecure
> default?".
> 
> 
in sshd_config

#PermitRootLogin yes
or
#PermitRootLogin no

I can connect using openssh-6 but not 7-xx

Thelma

[gentoo-user] openssh-7.1_p1-r2 won't allow "nxserver" to connect [continued]

[Bill Damage]

I have exactly the same problem mentioned in this thread. I think something 
changed and broke the authentication during an update. i found this message by 
Googling and just joined the mail list to ask for help. I have done everything 
mentioned in the thread, and here's where I'm at: (it worked fine before some 
regular update broke it)
Thanks!
[root@tiger ssh]# nxsetup --test
> Testing your nxserver configuration ...Warning: Invalid value 
"APPLICATION_LIBRARY_PRELOAD=/usr/lib64/nx/libX11.so.6:/usr/lib64/nx/libXext.so.6:/usr/lib64/nx/libXcomp.so.3:/usr/lib64/nx/libXcompext.so.3:/usr/lib64/nx/libXrender.so.1".
 /usr/lib64/nx/libX11.so.6 could not be found. Users will not be able to run a 
single application in non-rootless mode.Warning: Invalid value 
"COMMAND_START_CDE=cdwm"         Users will not be able to request a CDE 
session.Warning: Invalid value "COMMAND_SMBMOUNT=smbmount". You'll not be able 
to use SAMBA.Warning: Invalid value "COMMAND_SMBUMOUNT=smbumount". You'll not 
be able to use SAMBA.Warning: Invalid cupsd version of "/usr/sbin/cupsd". Need 
version 1.2.         Users will not be able to enable printing. Ignore if you 
use cups > 1.2Error: Could not find 1.5.0 or 2.[01].0 or 3.[012345].0 version 
string in nxagent. NX 1.5.0 or 2.[01].0 or 3.[012345].0 backend is needed for 
this version of FreeNX.
  Warnings occured during config check.  To enable these features please 
correct the configuration file.
< done
> Testing your nxserver connection ...Permission denied 
(publickey,gssapi-keyex,gssapi-with-mic,password).Fatal error: Could not 
connect to NX Server.
Please check your ssh setup:
The following are _examples_ of what you might need to check.
        - Make sure "nx" is one of the AllowUsers in sshd_config.    (or that 
the line is outcommented/not there)        - Make sure "nx" is one of the 
AllowGroups in sshd_config.    (or that the line is outcommented/not there)     
   - Make sure your sshd allows public key authentication.        - Make sure 
your sshd is really running on port 22.        - Make sure your sshd_config 
AuthorizedKeysFile in sshd_config is set to authorized_keys.    (this should be 
a filename not a pathname+filename)  - Make sure you allow ssh on localhost, 
this could come from some    restriction of:      -the tcp wrapper. Then add in 
/etc/hosts.allow: ALL:localhost      -the iptables. add to it:         $ 
iptables -A INPUT  -i lo -j ACCEPT         $ iptables -A OUTPUT -o lo -j 
ACCEPT[root@tiger ssh]#

Re: [gentoo-user] What do you use for appliances with old SSL?

[Mick]

On Wednesday 25 Nov 2015 07:11:39 J. Roeleveld wrote:
> On 25 November 2015 00:33:57 CET, Adam Carter  wrote:
> >It seems like modern browsers don't have the option to support old
> >crypto,
> >eg on firefox setting security.version.tls.min to 0 still blocks SSLv3.
> >What do you use to access old equipment?
> 
> A virtual machine with an old browser which is only used to access these
> devices.
> 
> --
> Joost

A less onerous method, but potentially more insecure unless you revert the 
setting for day to day usage, is to type 'about:config' and set 
security.tls.version.min to 0, before you restart FF.

-- 
Regards,
Mick


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

Re: [gentoo-user] openssh-7.1_p1-r2 won't allow "nxserver" to connect [continued]

[Mick]

On Wednesday 25 Nov 2015 20:04:14 Neil Bothwick wrote:
> On Wed, 25 Nov 2015 12:55:43 -0700, the...@sys-concept.com wrote:
> > > Which you would expect if that was not the problem. From memory, I
> > > think your problem was caused by password logins as root being
> > > disabled. That was another change for 7.0 and my only comment on that
> > > is "why the hell did they wait until version 7.0 before getting rid
> > > of such and insecure default?".
> > 
> > in sshd_config
> > 
> > #PermitRootLogin yes
> > or
> > #PermitRootLogin no
> > 
> > I can connect using openssh-6 but not 7-xx
> 
> Because the setting is commented out so it falls back to the default,
> which is yes in 6 and no in 7. Set it to what you need instead of relying
> on defaults which can change.

Also, check your *uncommented* setting for PermitEmptyPasswords, if for some 
reason you have not set up a password for your NX account.  The default is no.

-- 
Regards,
Mick


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

Re: [gentoo-user] openssh-7.1_p1-r2 won't allow "nxserver" to connect [continued]

[thelma]

On 11/25/2015 01:04 PM, Neil Bothwick wrote:
> On Wed, 25 Nov 2015 12:55:43 -0700, the...@sys-concept.com wrote:
> 
>>> Which you would expect if that was not the problem. From memory, I
>>> think your problem was caused by password logins as root being
>>> disabled. That was another change for 7.0 and my only comment on that
>>> is "why the hell did they wait until version 7.0 before getting rid
>>> of such and insecure default?".
>>>
>>>   
>> in sshd_config
>>
>> #PermitRootLogin yes
>> or
>> #PermitRootLogin no
>>
>> I can connect using openssh-6 but not 7-xx
> 
> Because the setting is commented out so it falls back to the default,
> which is yes in 6 and no in 7. Set it to what you need instead of relying
> on defaults which can change.

Yes, nxserver works with openssh-7; I don't know why I couldn't make it
to work during upgrade few weeks ago :-/

[gentoo-user] Weird "df" output

[waltdnes]

  I'll admit that my system setup is a bit unusual.  A long time ago, in
a place far away, hard drives were small, compared to today's standards.
The usual unix practice of multiple seprate partitions was not feasable
for me, but I did want to keep root on its own partition.  So I
compromised with a small / partition, with empty /home, /opt, /var,
/usr, and /tmp directories.  Their real equivalents are bind-mounted
from a much larger partition.  I just re-did my oldest machine.  It has
a primary partition 1, which covers the entire hard drive.  The /
partion on /dev/sda5 is approximately 500 megabytes (YES!).  There's a
3.8 gigabyte swap partion /dev/sda6, and the rest of the drive is
/dev/sda7.  Here's the relevant portion of /etc/fstab...

/dev/sda5   /   ext2 noatime,async  0 1
/dev/sda7   /home   ext3 noatime,async  0 1
/home/bindmounts/opt/optauto bind   0 0
/home/bindmounts/var/varauto bind   0 0
/home/bindmounts/usr/usrauto bind   0 0
/home/bindmounts/tmp/tmpauto bind   0 0
/dev/sda6   noneswap sw 0 0

...and the output from "df"...

Filesystem 1K-blocks  Used Available Use% Mounted on
/dev/root 495944 49416420928  11% /
devtmpfs   10240 0 10240   0% /dev
tmpfs 310080   356309724   1% /run
shm  1550384 0   1550384   0% /dev/shm
cgroup_root10240 0 10240   0% /sys/fs/cgroup
/dev/sda7  476205120 292365556 159643008  65% /opt

...showing /dev/sda7 mounted on /opt !?!?  mc (Midnight Commander) shows
152 of 454 gigabytes free on all of /home, /opt, /var, /usr, and /tmp,
which is correct, since they're all really bindmounts from /dev/sda7.
The / partition (/dev/sda5) has 411 of 484 megabytes free.  The machine
works OK, but the "df" output is a head-scratcher.  I've re-booted a
couple of times, with no change.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] openssh-7.1_p1-r2 won't allow "nxserver" to connect [continued]

[Neil Bothwick]

On Wed, 25 Nov 2015 12:55:43 -0700, the...@sys-concept.com wrote:

> > Which you would expect if that was not the problem. From memory, I
> > think your problem was caused by password logins as root being
> > disabled. That was another change for 7.0 and my only comment on that
> > is "why the hell did they wait until version 7.0 before getting rid
> > of such and insecure default?".
> > 
> >   
> in sshd_config
> 
> #PermitRootLogin yes
> or
> #PermitRootLogin no
> 
> I can connect using openssh-6 but not 7-xx

Because the setting is commented out so it falls back to the default,
which is yes in 6 and no in 7. Set it to what you need instead of relying
on defaults which can change.


-- 
Neil Bothwick

The people who are wrapped up in themselves are overdressed.


pgpFl1uth0Idu.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] openssh-7.1_p1-r2 won't allow "nxserver" to connect [continued]

[thelma]

On 11/25/2015 11:50 AM, Bill Damage wrote:
> I have exactly the same problem mentioned in this thread. I think something 
> changed and broke the authentication during an update. i found this message 
> by Googling and just joined the mail list to ask for help. I have done 
> everything mentioned in the thread, and here's where I'm at: (it worked fine 
> before some regular update broke it)
> Thanks!
> [root@tiger ssh]# nxsetup --test
> > Testing your nxserver configuration ...Warning: Invalid value 
> "APPLICATION_LIBRARY_PRELOAD=/usr/lib64/nx/libX11.so.6:/usr/lib64/nx/libXext.so.6:/usr/lib64/nx/libXcomp.so.3:/usr/lib64/nx/libXcompext.so.3:/usr/lib64/nx/libXrender.so.1".
>  /usr/lib64/nx/libX11.so.6 could not be found. Users will not be able to run 
> a single application in non-rootless mode.Warning: Invalid value 
> "COMMAND_START_CDE=cdwm" Users will not be able to request a CDE 
> session.Warning: Invalid value "COMMAND_SMBMOUNT=smbmount". You'll not be 
> able to use SAMBA.Warning: Invalid value "COMMAND_SMBUMOUNT=smbumount". 
> You'll not be able to use SAMBA.Warning: Invalid cupsd version of 
> "/usr/sbin/cupsd". Need version 1.2. Users will not be able to enable 
> printing. Ignore if you use cups > 1.2Error: Could not find 1.5.0 or 2.[01].0 
> or 3.[012345].0 version string in nxagent. NX 1.5.0 or 2.[01].0 or 
> 3.[012345].0 backend is needed for this version of FreeNX.
>   Warnings occured during config check.  To enable these features please 
> correct the configuration file.
> < done
> > Testing your nxserver connection ...Permission denied 
> (publickey,gssapi-keyex,gssapi-with-mic,password).Fatal error: Could not 
> connect to NX Server.
> Please check your ssh setup:
> The following are _examples_ of what you might need to check.
> - Make sure "nx" is one of the AllowUsers in sshd_config.(or that 
> the line is outcommented/not there)- Make sure "nx" is one of the 
> AllowGroups in sshd_config.(or that the line is outcommented/not there)   
>  - Make sure your sshd allows public key authentication.- Make 
> sure your sshd is really running on port 22.- Make sure your 
> sshd_config AuthorizedKeysFile in sshd_config is set to authorized_keys.
> (this should be a filename not a pathname+filename)  - Make sure you allow 
> ssh on localhost, this could come from somerestriction of:  -the tcp 
> wrapper. Then add in /etc/hosts.allow: ALL:localhost  -the iptables. add 
> to it: $ iptables -A INPUT  -i lo -j ACCEPT $ iptables -A 
> OUTPUT -o lo -j ACCEPT[root@tiger ssh]#
> 

I had the same problem.
openssh-7.xxx (screwed up) by disabling ssh-dss key (that is what
nxserver is using).
Trying to enable the "ssh-dss" via sshd_config does not work!

So the only way to go about it is to downgrade to openssh-6.xxx

--
Thelma

Re: [gentoo-user] What do you use for appliances with old SSL?

[Adam Carter]

>
> A less onerous method, but potentially more insecure unless you revert the
> setting for day to day usage, is to type 'about:config' and set
> security.tls.version.min to 0, before you restart FF.
>
>
Restarting doesnt help (with FF 42 at least). Message is "Firefox cannot
guarantee the safety of your data on  because it uses SSLv3, a broken
security protocol.
Advanced info: ssl_error_unsupported_version".

I'm using FF through stunnel at the moment and its good enough.

[gentoo-user] Bug-reporting best practice? Xen/Gentoo -- Preparing to log interrupt info sometime after feb. 2016.

[Håkon Alstadheim]

Hi all, I'm not a developer but I would like to set up my Xen system to
get bug reports as useful as possible. At present I am logging the xen
console via serial port, and I am running Xen compiled from gentoo
ebuild with "debug" use flag. Is there anything more I need to set up to
be able to collect as much useful info as possible?

At present, this is my xen command line:
xen_commandline: ssd-xen-debug-marker console_timestamps=date
loglvl=all guest_loglvl=all sync_console iommu=1,verbose,debug
iommu_inclusive_mapping=1 com1=115200,8n1 console=com1 dom0_max_vcpus=4
dom0_vcpus_pin=1 dom0_mem=8G,max:8G cpufreq=xen:performance,verbose
tmem=1 sched_smt_power_savings=1 apic_verbosity=debug e820-verbose=1
core_parking=power

(yes, I know, 8G for dom0, well, it is also acting as file server, I
want to keep as much of the file-system in cache as I can )

Any changes I should make for maximally useful bug-reports?

This is in preparation for the 4.7 release (april 2016 I gather) . I
have some PCIe cards that are acting up, something to do with
interrupts. I see some activity on that front right now, so I've decided
to be an early adopter of 4.7, to be able to help as much as possible,
maybe get any tweaks I might need for my system done in the source.

I'm running gentoo, and have tried installing xen-*- from the
virtualization overlay, but it fails, seems it is trying to fetch the
qemu sources twice, and failing.  Is it me doing something wrong? Use
flag "system-qemu" does not help.

---
Additional info:
The PCIe cards that are acting up are:
00:1b.0 Audio device: Intel Corporation C610/X99 series chipset HD Audio
Controller (rev 05)
02:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host
Controller
81:00.0 USB controller: ASMedia Technology Inc. Device 1242

Trying to pass them through to any domain is highly hit-or-miss. Seems
like interrupt set-up fails quite often, but I have not been able to
find any actual error-messages in any logs. The two first there are
built-in to the motherboard, the last one is an add-in card. I have
tried several other add-in cards for USB, all acting decidedly weird.

Re: [gentoo-user] dcron problem on new install

[J. Roeleveld]

On Wednesday, November 25, 2015 10:29:52 PM waltd...@waltdnes.org wrote:
>   I'm getting a bunch of messages like...
> 
> > Subject: cron for user root root[ ! -x /etc/cron.hourly/0anacron ]
> > && { test -x /usr/sbin/run-crons && /usr/sbin/run-crons ; }
> > 
> > /bin/sh: root: command not found
> 
> /bin/sh does exist...
> 
> [d531][waltdnes][~] ll /bin/sh
> lrwxrwxrwx 1 root root 4 Nov 24 12:10 /bin/sh -> bash
> 
> /etc/  cron.hourly  cron.weekly  cron.monthly   are empty except for a
> dummy file .keep_sys-process_cronbase-0

What do you get when you run:

# crontab -l

as root?

--
Joost

Re: [gentoo-user] dcron problem on new install

[Marc Joliet]

On Wednesday 25 November 2015 22:29:52 waltd...@waltdnes.org wrote:
>  I'm getting a bunch of messages like...
>
>> Subject: cron for user root root[ ! -x /etc/cron.hourly/0anacron ]
>> && { test -x /usr/sbin/run-crons && /usr/sbin/run-crons ; }
>> 
>> /bin/sh: root: command not found
>
>/bin/sh does exist...
>
>[d531][waltdnes][~] ll /bin/sh
>lrwxrwxrwx 1 root root 4 Nov 24 12:10 /bin/sh -> bash
>
>/etc/  cron.hourly  cron.weekly  cron.monthly   are empty except for a
>dummy file .keep_sys-process_cronbase-0

I remember from experience that those messages are misleading.  It's not dcron 
complaining about /bin/sh not existing, it's /bin/sh complaining about some 
command not existing.  In fact, bash's error message format indicates that 
something is trying to execute "root":

% bash -c "echl"
bash: echl: Kommando nicht gefunden.

(dash's error message would look like this:
% dash -c "echl"
dash: 1: echl: not found)

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] Re: emerging squid indefinitely

[lee]

walt  writes:

> On Tue, 24 Nov 2015 23:39:01 +0100
> lee  wrote:
>
>>
>> ...
>
>  
>> Well, ok, the file is still locked.
>> 
>> 'group-' looks like a backup, and 'group.lock' contains 10563, which
>> is the pid of groupadd.  I'd think that's ok.
>> 
>> So what all does it take to create a system group?  I suppose I could
>> kill groupadd and the emerging might go on, though I wonder what the
>> problem might be and if something else besides making an entry to
>> /etc/group needs to be done.  What might require an indefinite delay
>> here?
>
> Any unusual network activity?  (DNS lookups that shouldn't be
> happening, etc.) 

There's nothing suspicious in the firewall log and no unexpected DNS
queries.

The emerge before this one was apache, which I suppose also creates a
system group, and that worked just fine.

I'll probably reboot today or tomorrow because I need to have a
differently configured kernel running to be able to do some traffic
shaping.  If I do that, I'll probably just kill groupadd and see if the
merging continues.

Re: [gentoo-user] Re: emerging squid indefinitely

[Alan McKinnon]

On 26/11/2015 02:03, walt wrote:

On Wed, 25 Nov 2015 18:53:50 +0200
Alan McKinnon  wrote:


On 25/11/2015 13:30, lee wrote:

walt  writes:


On Tue, 24 Nov 2015 23:39:01 +0100
lee  wrote:



...






Any unusual network activity?  (DNS lookups that shouldn't be
happening, etc.)


There's nothing suspicious in the firewall log and no unexpected DNS
queries.


Ignore DNS, it has absolutely nothing to do with creating a group. A
common human trait in dealing with problems with unknown causes is to
start investigating all manner of weird and entirely unrelated things.


And Happy Thanksgiving to you, grouchy old fart living somewhere south
of the equator where no one celebrates Thanksgiving :)


That's true enough. But we do celebrate bloodletting day round about the 
same time (commemorates some battle or other), and most of the rest of 
the population celebrates thankstaking. Oh well


IIRC I learned about DNS queries causing delays directly from you.

Well, maybe it was some other old fart on this list.


There's enough of us old farts here, you can blame any one of us for 
anything and get away with it :-)


Alan

Re: [gentoo-user] Re: emerging squid indefinitely

[Alan McKinnon]

On 26/11/2015 01:33, lee wrote:

Alan McKinnon  writes:


On 25/11/2015 13:30, lee wrote:

walt  writes:


On Tue, 24 Nov 2015 23:39:01 +0100
lee  wrote:



...




Well, ok, the file is still locked.

'group-' looks like a backup, and 'group.lock' contains 10563, which
is the pid of groupadd.  I'd think that's ok.

So what all does it take to create a system group?  I suppose I could
kill groupadd and the emerging might go on, though I wonder what the
problem might be and if something else besides making an entry to
/etc/group needs to be done.  What might require an indefinite delay
here?



[...]

I'll probably reboot today or tomorrow because I need to have a
differently configured kernel running to be able to do some traffic
shaping.  If I do that, I'll probably just kill groupadd and see if the
merging continues.


The group is already created so kill groupadd. One of three things will
happen:

1. the emerge will continue. Do nothing
2. The emerge will fail with a groupadd error. Restart the emerge
3. Nothing will change. Kill the emerge and restart it

If the lockfile persists after killing groupadd, delete it.


Well, yes ... I just would like to know what the problem might be.



I doubt you'll ever find out. Something went wrong, a process hung and 
it's likely a once off. Deal with it, move on.