Re: [gentoo-user] Fail2Ban vs SSHGuard? Comparison? What's the difference?

[Alan McKinnon]

On 16/09/2017 23:25, Stroller wrote:
> 
>> On 16 Sep 2017, at 20:31, Alan McKinnon  wrote:
>>
>> As far as I'm aware (and could be wrong), sshguard is mostly just sshd
>> whereas fail2ban works on anything you can give it consistent logs for.
> 
> I thought otherwise, but you appear to be right - SSHGuard appears to have 
> only a handful of "signatures", so it looks like Fail2Ban it is.
> 
> https://www.sshguard.net/docs/reference/attack-signatures/


I reckon too, you did say folding in IMAP would also be cool.

As a sidenote, I've just finished rolling out fail2ban here at work.
It's a mobile provider and ISP with millions and millions of hones out
there, and the owners has some very odd ideas on how mail works.
Especially just how much mail coming from their individual phones I'm
willing to relay (answer: not very much at all :-) )

Anyway, fail2ban went on the mail relays with strict rules as to number
of connections etc etc. The amount of tweaking I had to make was minimal
- just change some numbers. All the rules I needed were already there
baked in, I just had to enable them and set the numbers. It even knew
these are FreeBSD relays so the packet filter is pf.

It's such a pleasure to use a product built with real engineering in
mind and does it right. fail2ban ticks that box for me.

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

Re: [gentoo-user] Fail2Ban vs SSHGuard? Comparison? What's the difference?

[Stroller]

> On 16 Sep 2017, at 20:31, Alan McKinnon  wrote:
> 
> As far as I'm aware (and could be wrong), sshguard is mostly just sshd
> whereas fail2ban works on anything you can give it consistent logs for.

I thought otherwise, but you appear to be right - SSHGuard appears to have only 
a handful of "signatures", so it looks like Fail2Ban it is.

https://www.sshguard.net/docs/reference/attack-signatures/

Stroller.

Re: [gentoo-user] scary (?) situation with binutils

[Alan McKinnon]

On 16/09/2017 22:31, allan gottlieb wrote:
> I am one of the users experiencing the
>infinite rebuild of binutils
> bug.  Today it took a turn I find worrisome


Replying here so it's at the top.

Several things are happening, but I suppose the primary one is (and I
sorts need to be direct here):

Stop being scared and stop being confused by the big words. It's
blinding you to what is right there is plain sight right in front of you.

binutils has a history of getting itself and portage confused as to what
it needs and does not need with respect to preserved-rebuild. A few
other packages do this as well over the years. The most direct solution
is to simply unmerge the package, letting portage clean out the slate
and all the cruft, then merge the package back. The junk goes away,
portage sorts itself out, and stops it's whining.

The wrinkle as you point out is that you can't merge binutils without
bintils as you need ld. But never fear! this is Gentoo and you have all
the tools. Just quickpkg it, unmerge the damn thing and untar it back
like all the advise you've read tells you to do. Now you have an ld and
can properly merge binutils, so do so. portage will complain about file
collisions as expected, but because you are doing this in "yes, I DO
know what I am doing" mode, say yes.

That should fix your preserved-rebuild.


Now, for the masking notice. This is a completely different thing and
the only similarlity is that this sequence of letters "b,i,n,u,t,i,l,s"
shows up in both.

binutils is slotted. You have 2.28.1 and the mask applies to 2.25.1-r1
Portage is really saying "Yo dude, so this binutils you have? I've been
told to mask it and not just use it. You need to tell me if you want to
use it anyway, or if I can kill it with fire, or what."

It's a simple problem of deciding what you want to do. 2.25 is ancient,
so if you have it installed for some reason, you should find out why and
deal with that. It's probably safe, but you do need to find why you have
it first. Then proceed as a routine package removal (which is actually
all this is).


> 
> To summarize for months now after every emerge I get
> 
> !!! existing preserved libs:
> >>> package: sys-libs/binutils-libs-2.28.1
>  *  - /usr/lib64/libbfd-2.25.1.so
>  *  used by
> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so
> (sys-devel/binutils-2.25.1-r1)
> Use emerge @preserved-rebuild to rebuild packages using these libraries
> 
> If if then
> emerge @preserved-rebuild
> it rebuilds binutils but I still get the above message.  I have rebuilt
> it at least a dozen times in the past months.
> 
> A solution was posted that involved making a quickpkg (I think),
> unmerging binutils, and then manually untaring (after the unmerge of
> binutils you can't simply remerge since ld is gone).
> 
> This solution frightened me and I am living with always being told to run
>emerge @preserved-rebuild
> and actually doing that fruitless emerge about once a month.
> 
> Today was different, I guess because binutils-lib was involved
> 
> My "twice-weekly"
>emerge --update --changed-use --with-bdeps=y @world
> resulted in
> Calculating dependencies... done!
> [ebuild  NS] sys-kernel/gentoo-sources-4.12.12 [3.10.3-r1, 3.11.0, 
> 3.12.13, 3.18.11, 3.18.12, 4.0.5, 4.0.9, 4.1.12, 4.1.15-r1, 4.4.6, 4.4.21, 
> 4.4.26, 4.4.39, 4.9.6-r1, 4.9.16, 4.9.34, 4.12.5] USE="-build -experimental 
> -symlink" 
> [ebuild U  ] www-plugins/adobe-flash-27.0.0.130-r1 [27.0.0.130]
> [ebuild  rR]  x11-libs/cairo-1.14.8 
> [ebuild  r  U  ]   sys-libs/binutils-libs-2.28.1 [2.28-r1]
> 
> The following packages are causing rebuilds:
> 
>   (sys-libs/binutils-libs-2.28.1:0/2.28.1::gentoo, ebuild scheduled for 
> merge) causes rebuilds for:
> (x11-libs/cairo-1.14.8:0/0::gentoo, ebuild scheduled for merge)
> 
> When the emerge finished I received the usual
> 
> !!! existing preserved libs:
 package: sys-libs/binutils-libs-2.28.1
>  *  - /usr/lib64/libbfd-2.25.1.so
>  *  used by 
> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so 
> (sys-devel/binutils-2.25.1-r1)
> Use emerge @preserved-rebuild to rebuild packages using these libraries
> 
> But when I ran
>   emerge @preserved-rebuild
> out came the following
> 
>   The following mask changes are necessary to proceed:
>(see "package.unmask" in the portage(5) man page for more details)
>   # required by @preserved-rebuild (argument)
>   # /var/portage/profiles/package.mask:
>   # Michał Górny , Andreas K. Hüttel 
> ,
>   # Matthias Maier  (21 May 2017)
>   # These old versions of toolchain packages (binutils, gcc, glibc) are no
>   # longer officially supported and are not suitable for general use. Using
>   # these packages can result in build failures (and possible breakage) for
>   # many packages, and may leave your system vulnerable to known security
>   # exploits.
>   

[gentoo-user] scary (?) situation with binutils

[allan gottlieb]

I am one of the users experiencing the
   infinite rebuild of binutils
bug.  Today it took a turn I find worrisome

To summarize for months now after every emerge I get

!!! existing preserved libs:
>>> package: sys-libs/binutils-libs-2.28.1
 *  - /usr/lib64/libbfd-2.25.1.so
 *  used by
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so
(sys-devel/binutils-2.25.1-r1)
Use emerge @preserved-rebuild to rebuild packages using these libraries

If if then
emerge @preserved-rebuild
it rebuilds binutils but I still get the above message.  I have rebuilt
it at least a dozen times in the past months.

A solution was posted that involved making a quickpkg (I think),
unmerging binutils, and then manually untaring (after the unmerge of
binutils you can't simply remerge since ld is gone).

This solution frightened me and I am living with always being told to run
   emerge @preserved-rebuild
and actually doing that fruitless emerge about once a month.

Today was different, I guess because binutils-lib was involved

My "twice-weekly"
   emerge --update --changed-use --with-bdeps=y @world
resulted in
Calculating dependencies... done!
[ebuild  NS] sys-kernel/gentoo-sources-4.12.12 [3.10.3-r1, 3.11.0, 3.12.13, 
3.18.11, 3.18.12, 4.0.5, 4.0.9, 4.1.12, 4.1.15-r1, 4.4.6, 4.4.21, 4.4.26, 
4.4.39, 4.9.6-r1, 4.9.16, 4.9.34, 4.12.5] USE="-build -experimental -symlink" 
[ebuild U  ] www-plugins/adobe-flash-27.0.0.130-r1 [27.0.0.130]
[ebuild  rR]  x11-libs/cairo-1.14.8 
[ebuild  r  U  ]   sys-libs/binutils-libs-2.28.1 [2.28-r1]

The following packages are causing rebuilds:

  (sys-libs/binutils-libs-2.28.1:0/2.28.1::gentoo, ebuild scheduled for merge) 
causes rebuilds for:
(x11-libs/cairo-1.14.8:0/0::gentoo, ebuild scheduled for merge)

When the emerge finished I received the usual

!!! existing preserved libs:
>>> package: sys-libs/binutils-libs-2.28.1
 *  - /usr/lib64/libbfd-2.25.1.so
 *  used by 
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so 
(sys-devel/binutils-2.25.1-r1)
Use emerge @preserved-rebuild to rebuild packages using these libraries

But when I ran
  emerge @preserved-rebuild
out came the following

  The following mask changes are necessary to proceed:
   (see "package.unmask" in the portage(5) man page for more details)
  # required by @preserved-rebuild (argument)
  # /var/portage/profiles/package.mask:
  # Michał Górny , Andreas K. Hüttel ,
  # Matthias Maier  (21 May 2017)
  # These old versions of toolchain packages (binutils, gcc, glibc) are no
  # longer officially supported and are not suitable for general use. Using
  # these packages can result in build failures (and possible breakage) for
  # many packages, and may leave your system vulnerable to known security
  # exploits.
  # If you still use one of these old toolchain packages, please upgrade (and
  # switch the compiler / the binutils) ASAP. If you need them for a specific
  # (isolated) use case, feel free to unmask them on your system.
  =sys-devel/binutils-2.25.1-r1
  
  NOTE: The --autounmask-keep-masks option will prevent emerge
from creating package.unmask or ** keyword changes.

  Would you like to add these changes to your config files? [Yes/No]

I said no since I don't want to unmask, but am not sure how to proceed

Thanks in advance for any help.

allan

Re: [gentoo-user] Fail2Ban vs SSHGuard? Comparison? What's the difference?

[Alan McKinnon]

On 16/09/2017 16:06, Stroller wrote:
> Is anyone familiar enough with this subject to make a comparison between 
> these two programs, please?
> 
> If I google Fail2Ban vs SSHGuard I get many hits saying "I use this one", but 
> no-one saying why one might be better than the other.
> 
> So far I'm favouring SSHGuard, but mostly because the website looks prettier.
> 
> I want to be able to use passwords, so allowing logons only by public-key is 
> no good (also would be nice to block failed IMAP connection attempts).
> 
> Thanks in advance for any thoughts. 
> 
> Stroller.
> 


Depends what you want, they both achieve the same end. fail2ban reads
all manner of log files and such, decides based on rules if someone is
being naughty, and then takes actually (most often listing the source
address in a packet filter drop rule).

As far as I'm aware (and could be wrong), sshguard is mostly just sshd
whereas fail2ban works on anything you can give it consistent logs for.
There's not much to choose between them really.

So go for the one that seems to fit your needs best, if you scan the man
pages and sample rules files and one jumps out as a clear winner than
you understand easily, then that is the one you use.

The question is almost never "does this things do what I want?" as the
answer is so often yes. The question is always "d I understand this
thing as can drive it easily?"

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

Re: [gentoo-user] Re: [offtopic] Copy-On-Write ?

[Rich Freeman]

On Sat, Sep 16, 2017 at 1:48 PM, Kai Krakow  wrote:
> Am Sat, 16 Sep 2017 10:05:21 -0700
> schrieb Rich Freeman :
>
>>
>> My main concern with xfs/ext4 is that neither provides on-disk
>> checksums or protection against the raid write hole.
>
> Btrfs suffers the same RAID5 write hole problem since years. I always
> planned moving to RAID5 later (which is why I have 3 disks) but I fear
> this won't be fixed any time soon due to design decisions made too
> early.
>

Btrfs RAID5 simply doesn't work.  I don't think it was ever able to
recover from a failed drive - it really only exists so that they can
develop it.

>
>> I just switched motherboards a few weeks ago and either a connection
>> or a SATA port was bad because one of my drives was getting a TON of
>> checksum errors on zfs.  I moved it to an LSI card and scrubbed, and
>> while it took forever and the system degraded the array more than once
>> due to the high error rate, eventually it patched up all the errors
>> and now the array is working without issue.  I didn't suffer more than
>> a bit of inconvenience but with even mdadm raid1 I'd have had a HUGE
>> headache trying to recover from that (doing who knows how much
>> troubleshooting before realizing I had to do a slow full restore from
>> backup with the system down).
>
> I found md raid not very reliable in the past but I didn't try again in
> years. So this may have changed. I only remember it destroyed a file
> system after an unclean shutdown not only once, that's not what I
> expect from RAID1. Other servers with file systems on bare metal
> survived this just fine.
>

mdadm provides no protection against either silent corruption or the
raid hole.

If your system dies/panics/etc while it is in the middle of writing a
stripe, then whatever previously occupied the space in that stripe is
likely to be lost.

If your hard drive writes something to disk other than what the OS
told it to write, you'll also be likely to lose a stripe unless you
want to try to manually repair it (in theory you could try to process
the data manually excluding each of the drives and try to work out
which version of the data is correct, and then do that for every
damaged stripe).

Sure, both failure modes are rare, but they still exist.  The fact
that you haven't personally experienced them doesn't change that.

If I had been using mdadm a few weeks ago I'd be restoring from
backups.  The software would have worked fine, but if the disk doesn't
write what it was supposed to write, and the software has no way to
recover from this, then you're up the creek.  With zfs and btrfs you
aren't dependent on the drive hardware detecting and reporting errors.
(In my case there were no errors reported by the drive at all for any
of this.  I suspect the issue was in the SATA port or something else
on the motherboard.  I haven't tried plugging in a scratch drive to
try to debug it, but I will be taking care not to use that port in the
future.)

>
> I think the reasoning using own caching is, that block caching at the
> vfs layer cannot just be done in an efficient way for a cow file system
> with scrubbing and everything.

Btrfs doesn't appear to have any issues despite being COW.  There
might or might not be truth to your statement.

However, I think the real reason that ZFS on Linux uses its own cache
is just because it made it easier to just port the code over wholesale
by doing it this way.  The goal of migrating the existing code was to
reduce the risk of regressions, which is why ZFS on Linux works as
well as it does.  It would take them a long time to replace the
caching layer and there would be a lot of risk of introducing errors
along the way, so it just isn't as high a priority as getting it
running in the first place.  Plus ZFS has a bunch of both read and
write cache features which aren't really built into the kernel as far
as I'm aware.  Sure, there is bcache and so on, but that isn't part of
the regular kernel cache.  Rewriting ZFS to do things the linux way
would be down the road, and it wouldn't help them get it into the
mainline kernel anyway due to the licensing issue.


-- 
Rich

Re: [gentoo-user] thin-provisioning-tools - but I don't provision anything!!!!!

[Stroller]

> On 16 Sep 2017, at 17:16, Peter Humphrey  wrote:
> On Saturday, 16 September 2017 15:35:44 BST Alan Mackenzie wrote:
> 
>> What really got up my nose, as mentioned above, was doing an emerge -s on
>> thing-provisioning-tools and getting told it was "tools for thin
>> provisioning".
> 
> I raised a bug report about that once, against use.desc. There was a flurry 
> of activity as devs looked around their own bailiwicks and fixed them, then 
> everything went quiet again.

Really? 

I started threads at least twice on gentoo-dev (now years ago), and it seemed 
to have no effect.

I've given up expecting USE descriptions to be useful.

> It's an example of no designer or coder enjoying any of the still important 
> bits left over when the acceptance test is passed.

+1

Stroller.

[gentoo-user] Re: [offtopic] Copy-On-Write ?

[Kai Krakow]

Am Sat, 16 Sep 2017 10:05:21 -0700
schrieb Rich Freeman :

> On Sat, Sep 16, 2017 at 9:43 AM, Kai Krakow 
> wrote:
> >
> > Actually, I'm running across 3x 1TB here on my desktop, with mraid1
> > and draid 0. Combined with bcache it gives confident performance.
> >  
> 
> Not entirely sure I'd use the word "confident" to describe a
> filesystem where the loss of one disk guarantees that:
> 1.  You will lose data (no data redundancy).
> 2.  But the filesystem will be able to tell you exactly what data you
> lost (as metadata will be fine).

I take daily backups with borg backup. It takes only 15 minutes to run.
And it has been tested twice successfully. The only breakdowns I had
were due to btrfs bugs, not hardware faults.

This is confident enough for my desktop system.


> > I was very happy a long time with XFS but switched to btrfs when it
> > became usable due to compression and stuff. But performance of
> > compression seems to get worse lately, IO performance drops due to
> > hogged CPUs even if my system really isn't that incapable.
> >  
> 
> Btrfs performance is pretty bad in general right now.  The problem is
> that they just simply haven't gotten around to optimizing it fully,
> mainly because they're more focused on getting rid of the data
> corruption bugs (which is of course the right priority).  For example,
> with raid1 mode btrfs picks the disk to use for raid based on whether
> the PID is even or odd, without any regard to disk utilization.
> 
> When I moved to zfs I noticed a huge performance boost.

Interesting... While I never tried it I always feared that it would
perform worse if not throwing RAM and ZIL/L2ARC at it.


> Fundamentally I don't see why btrfs can't perform just as well as the
> others.  It just isn't there yet.

And it will take a long time still, because devs are still throwing new
features at it which need to stabilize.


> > What's still cool is that I don't need to manage volumes since the
> > volume manager is built into btrfs. XFS on LVM was not that
> > flexible. If btrfs wouldn't have this feature, I probably would
> > have switched back to XFS already.  
> 
> My main concern with xfs/ext4 is that neither provides on-disk
> checksums or protection against the raid write hole.

Btrfs suffers the same RAID5 write hole problem since years. I always
planned moving to RAID5 later (which is why I have 3 disks) but I fear
this won't be fixed any time soon due to design decisions made too
early.


> I just switched motherboards a few weeks ago and either a connection
> or a SATA port was bad because one of my drives was getting a TON of
> checksum errors on zfs.  I moved it to an LSI card and scrubbed, and
> while it took forever and the system degraded the array more than once
> due to the high error rate, eventually it patched up all the errors
> and now the array is working without issue.  I didn't suffer more than
> a bit of inconvenience but with even mdadm raid1 I'd have had a HUGE
> headache trying to recover from that (doing who knows how much
> troubleshooting before realizing I had to do a slow full restore from
> backup with the system down).

I found md raid not very reliable in the past but I didn't try again in
years. So this may have changed. I only remember it destroyed a file
system after an unclean shutdown not only once, that's not what I
expect from RAID1. Other servers with file systems on bare metal
survived this just fine.


> I just don't see how a modern filesystem can get away without having
> full checksum support.  It is a bit odd that it has taken so long for
> Ceph to introduce it, and I'm still not sure if it is truly
> end-to-end, or if at any point in its life the data isn't protected by
> checksums.  If I were designing something like Ceph I'd checksum the
> data at the client the moment it enters storage, then independently
> store the checksum and data, and then retrieve both and check it at
> the client when the data leaves storage.  Then you're protected
> against corruption at any layer below that.  You could of course have
> additional protections to catch errors sooner before the client even
> sees them.  I think that the issue is that Ceph was really designed
> for object storage originally and they just figured the application
> would be responsible for data integrity.

I'd at least pass the checksum through all the layers while checking it
again, so you could detect which transport or layer is broken.


> The other benefit of checksums is that if they're done right scrubs
> can go a lot faster, because you don't have to scrub all the
> redundancy data synchronously.  You can just start an idle-priority
> read thread on every drive and then pause it anytime a drive is
> accessed, and an access on one drive won't slow down the others.  With
> traditional RAID you have to read all the redundancy data
> synchronously because you can't check the integrity of any of it
> without the full set.  

Re: [gentoo-user] Re: [offtopic] Copy-On-Write ?

[Rich Freeman]

On Sat, Sep 16, 2017 at 9:43 AM, Kai Krakow  wrote:
>
> Actually, I'm running across 3x 1TB here on my desktop, with mraid1 and
> draid 0. Combined with bcache it gives confident performance.
>

Not entirely sure I'd use the word "confident" to describe a
filesystem where the loss of one disk guarantees that:
1.  You will lose data (no data redundancy).
2.  But the filesystem will be able to tell you exactly what data you
lost (as metadata will be fine).

>
> I was very happy a long time with XFS but switched to btrfs when it
> became usable due to compression and stuff. But performance of
> compression seems to get worse lately, IO performance drops due to
> hogged CPUs even if my system really isn't that incapable.
>

Btrfs performance is pretty bad in general right now.  The problem is
that they just simply haven't gotten around to optimizing it fully,
mainly because they're more focused on getting rid of the data
corruption bugs (which is of course the right priority).  For example,
with raid1 mode btrfs picks the disk to use for raid based on whether
the PID is even or odd, without any regard to disk utilization.

When I moved to zfs I noticed a huge performance boost.

Fundamentally I don't see why btrfs can't perform just as well as the
others.  It just isn't there yet.

> What's still cool is that I don't need to manage volumes since the
> volume manager is built into btrfs. XFS on LVM was not that flexible.
> If btrfs wouldn't have this feature, I probably would have switched
> back to XFS already.

My main concern with xfs/ext4 is that neither provides on-disk
checksums or protection against the raid write hole.

I just switched motherboards a few weeks ago and either a connection
or a SATA port was bad because one of my drives was getting a TON of
checksum errors on zfs.  I moved it to an LSI card and scrubbed, and
while it took forever and the system degraded the array more than once
due to the high error rate, eventually it patched up all the errors
and now the array is working without issue.  I didn't suffer more than
a bit of inconvenience but with even mdadm raid1 I'd have had a HUGE
headache trying to recover from that (doing who knows how much
troubleshooting before realizing I had to do a slow full restore from
backup with the system down).

I just don't see how a modern filesystem can get away without having
full checksum support.  It is a bit odd that it has taken so long for
Ceph to introduce it, and I'm still not sure if it is truly
end-to-end, or if at any point in its life the data isn't protected by
checksums.  If I were designing something like Ceph I'd checksum the
data at the client the moment it enters storage, then independently
store the checksum and data, and then retrieve both and check it at
the client when the data leaves storage.  Then you're protected
against corruption at any layer below that.  You could of course have
additional protections to catch errors sooner before the client even
sees them.  I think that the issue is that Ceph was really designed
for object storage originally and they just figured the application
would be responsible for data integrity.

The other benefit of checksums is that if they're done right scrubs
can go a lot faster, because you don't have to scrub all the
redundancy data synchronously.  You can just start an idle-priority
read thread on every drive and then pause it anytime a drive is
accessed, and an access on one drive won't slow down the others.  With
traditional RAID you have to read all the redundancy data
synchronously because you can't check the integrity of any of it
without the full set.  I think even ZFS is stuck doing synchronous
reads due to how it stores/computes the checksums.  This is something
btrfs got right.

>
>>  For the moment I'm
>> relying more on zfs.
>
> How does it perform memory-wise? Especially, I'm currently using bees[1]
> for deduplication: It uses a 1G memory mapped file (you can choose
> other sizes if you want), and it picks up new files really fast, within
> a minute. I don't think zfs can do anything like that within the same
> resources.

I'm not using deduplication, but my understanding is that zfs deduplication:
1.  Works just fine.
2.  Uses a TON of RAM.

So, it might not be your cup of tea.  There is no way to do
semi-offline dedup as with btrfs (not really offline in that the
filesystem is fully running - just that you periodically scan for dups
and fix them after the fact, vs detect them in realtime).With a
semi-offline mode then the performance hits would only come at a time
of my choosing, vs using gobs of RAM all the time to detect what are
probably fairly rare dups.

That aside, I find it works fine memory-wise (I don't use dedup).  It
has its own cache system not integrated fully into the kernel's native
cache, so it tends to hold on to a lot more ram than other
filesystems, but you can tune this behavior so that it stays fairly
tame.

-- 
Rich

[gentoo-user] Re: [offtopic] Copy-On-Write ?

[Kai Krakow]

Am Sat, 16 Sep 2017 09:39:33 -0400
schrieb Rich Freeman :

> On Sat, Sep 16, 2017 at 8:06 AM, Kai Krakow 
> wrote:
> >
> > But I guess that btrfs doesn't use 10G sized extents? And I also
> > guess, this is where autodefrag jumps in.
> >  
> 
> It definitely doesn't use 10G extents considering the chunks are only
> 1GB.  (For those who aren't aware, btrfs divides devices into chunks
> which basically act like individual sub-devices to which operations
> like mirroring/raid/etc are applied.  This is why you can change raid
> modes on the fly - the operation takes effect on new chunks.  This
> also allows clever things like a "RAID1" on 3x1TB disks to have 1.5TB
> of useful space, because the chunks essentially balance themselves
> across all three disks in pairs.  It also is what causes the infamous
> issues when btrfs runs low on space - once the last chunk is allocated
> it can become difficult to rebalance/consolidate the remaining space.)

Actually, I'm running across 3x 1TB here on my desktop, with mraid1 and
draid 0. Combined with bcache it gives confident performance.


> I couldn't actually find any info on default extent size.  I did find
> a 128MB example in the docs, so presumably that isn't an unusual size.
> So, the 1MB example would probably still work.  Obviously if an entire
> extent becomes obsolete it will lose its reference count and become
> free.

According to bees[1] source code it's 128M actually if I remember right.


> Defrag was definitely intended to deal with this.  I haven't looked at
> the state of it in ages, when I stopped using it due to a bug and some
> limitations.  The main limitation being that defrag at least used to
> be over-zealous.  Not only would it free up the 1MB of wasted space,
> as in this example, but if that 1GB file had a reflink clone it would
> go ahead and split it into two duplicate 1GB extents.  I believe that
> dedup would do the reverse of this.  Getting both to work together
> "the right way" didn't seem possible the last time I looked into it,
> but if that has changed I'm interested.
> 
> Granted, I've been moving away from btrfs lately, due to the fact that
> it just hasn't matured as I originally thought it would.  I really
> love features like reflinks, but it has been years since it was
> "almost ready" and it still tends to eat data.

XFS has gained reflinks lately, and I think they are working on
snapshots currently. Kernel 4.14 or 4.15 promises new features for XFS
(if they get ready by then), so maybe that will be snapshots? I'm not
sure.

I was very happy a long time with XFS but switched to btrfs when it
became usable due to compression and stuff. But performance of
compression seems to get worse lately, IO performance drops due to
hogged CPUs even if my system really isn't that incapable.

What's still cool is that I don't need to manage volumes since the
volume manager is built into btrfs. XFS on LVM was not that flexible.
If btrfs wouldn't have this feature, I probably would have switched
back to XFS already.


>  For the moment I'm
> relying more on zfs.

How does it perform memory-wise? Especially, I'm currently using bees[1]
for deduplication: It uses a 1G memory mapped file (you can choose
other sizes if you want), and it picks up new files really fast, within
a minute. I don't think zfs can do anything like that within the same
resources.


>  I'd love to switch back if they ever pull things
> together.  The other filesystem I'm eyeing with interest is cephfs,
> but that still is slightly immature (on-disk checksums were only just
> added), and it has a bit of overhead until you get into fairly large
> arrays.  Cheap arm-based OSD options seem to be fairly RAM-starved at
> the moment as well given the ceph recommendation of 1GB/TB.  arm64
> still seems to be slow to catch on, let alone cheap boards with 4-16GB
> of RAM.

Well, for servers, XFS is still my fs of choice. But I will be
evaluating btrfs for that soon, maybe compare it to zfs. When we
evaluated the resource usage, we will buy matching hardware and setup a
new server, mainly for thin-provisioning container systems for web
hostings. I guess, ZFS would be somewhat misused here as DAS.

If XFS gets into shape anytime soon with snapshotting features, I will
of course consider it. Using it since years and it was extremely
reliable, surviving power losses, not degrading in performance.
Something I cannot say the same about for ext3, apparently. Also, XFS
gives good performance with JBOD because allocations are distributed
diagonally across the whole device. This is good for cheap hardware as
well as hardware raid controllers.

[1]: https://github.com/Zygo/bees


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] thin-provisioning-tools - but I don't provision anything!!!!!

[Peter Humphrey]

On Saturday, 16 September 2017 15:35:44 BST Alan Mackenzie wrote:

> What really got up my nose, as mentioned above, was doing an emerge -s on
> thing-provisioning-tools and getting told it was "tools for thin
> provisioning".

I raised a bug report about that once, against use.desc. There was a flurry 
of activity as devs looked around their own bailiwicks and fixed them, then 
everything went quiet again.

It's an example of no designer or coder enjoying any of the still important 
bits left over when the acceptance test is passed.

> What really takes up time maintaining a computer, or
> programming for that matter, is continually having to look somewhere else
> for something.  Even though I doubt it was deliberately designed to
> annoy, that emerge -s entry could hardly have been more annoying if
> somebody had tried to make it so.

Quite so.

-- 
Regards,
Peter.

Speak severely to your boy
And beat him when he sneezes.
He only does it to annoy
Because he knows it teases.

Re: [gentoo-user] locale no longer recognised by Plasma and KDE apps?

[Peter Humphrey]

On Saturday, 16 September 2017 16:00:43 BST Mick wrote:
> On Saturday, 16 September 2017 13:27:18 BST Marc Joliet wrote:
> > Am Mittwoch, 13. September 2017, 19:07:20 CEST schrieb Mick:
> > > Another little problem I came across with Plasma is that neither the
> > > keyboard, nor the spell checking respects the locale, L10N, or
> > > anything
> > > else I have set up.  systemsettings5 shows en-GB as the selected
> > > language
> > > and keyboard, but (I think) a US keyboard layout and spell checking
> > > language is used instead.
> > 
> > I have a slightly different problem with recent Plasma versions, but I
> > wonder if they're related:
> > 
> > Changing the spell checking language doesn't do anything, it sticks to
> > whatever was selected to begin with, even though it *looks* like I
> > changed the selection.  For example, if German is the initial
> > selection, after changing to any English variant English-only words are
> > still highlighted as incorrect.
> > 
> > I did just test changing the keyboard, though, and that still works (via
> > the default Ctrl-Alt-k keybinding).
> 
> Ahh!  This is interesting.  It only showed US keyboard being available. 
> So I looked into systemsettings5 and I discovered only US keyboard was
> listed.  So, I added the UK keyboard and this seems to have fixed the
> keyboard problem. Thanks for the hint.

First thing I do when setting up a new KDE account - and I've done it so 
many times in recent weeks that I lost count long ago. Keyboard, then 
regional settings and only after that the visual aspects.

-- 
Regards,
Peter.

Re: [gentoo-user] [OT] Choice of KVM?

[Peter Humphrey]

On Saturday, 16 September 2017 15:43:39 BST Alan Mackenzie wrote:
> Hello, Peter.
> 
> On Sat, Sep 16, 2017 at 15:00:16 +0100, Peter Humphrey wrote:
> > Hello list,
> > 
> > I didn't know where else to ask this, or I'd have spared you the
> > annoyance. Apologies if needed.
> > 
> > I need to replace a 4-port KVM switch by StarTech, which has failed
> > twice - that is, the original failed and its replacement has as well.
> > 
> > Two makes present themselves: Aten and Belkin. Does anyone have an
> > opinion on which is better? They seem to have similar abililties and
> > /modi operandi/.
> 
> All I can say is that I bought an ATEN KVM box some months ago to help
> in installing Gentoo on my new box.  It's V is two DVI connections, and
> it also connects up audio.
> 
> It has performed flawlessly.  The only slight problem has been the
> sluggishness in switching between machines - it takes well over a
> second.
> 
> I have no experience with Belkin's KVMs.

Well, thank you all. I didn't expect anyone to answer.

-- 
Regards,
Peter.

Re: [gentoo-user] [OT] Choice of KVM?

[mad.scientist.at.large]

actually, there are not kvm chips in existence, kvms are different than 
eachother.  many barely have a latch/counter chip (hundreds of ways if you're 
not using a micorcontroller, if you are then millions of ways).  the cheap ones 
just use a bunch of small field effect transistors. some(like mine, gritting 
teeth) don't connect the datalines that let the computer know what monitor it 
is and hence limits the resolution i can set on it.  better kvm units not only 
connect the data lines on the monitor (i2c is the protocol, electrically at 
least) but remember and tell any machine that ask what the monitor specs are.  
doubtless many use "analog switch" chips to switch things around.  likely any 
chip in a kvm is a microcontroller with custom code or a full custom chip, and 
it will likely still need additional chips to function.  then there are the 
dongles that let you control the computer and see what would be on a display if 
one were there, they use ip protocols to run all the video etc. over ethernet, 
usually a seperate network with it's own switch.  if it's cheap, it will be 
cheaply and poorly made, and likely will come with monitor cables that don't 
have all the wires they should, and hence don't play well with others (very bad 
in a kvm).   there is at least one company making very, very expensive KVMs 
that can work with other types of computers, i.e. the machines used for 
animation in movies, i.e. not vga, not dvi, not usb, not like on a pc, more 
like workstations, and some of those are fairly unique in terms of the cables, 
connectors, and sofware interfaces.

--
The Power Of the People Is Stronger Than The People In Charge.


16. Sep 2017 08:35 by strol...@stellar.eclipse.co.uk:


>> On 16 Sep 2017, at 15:19, Peter Humphrey <>> pe...@prh.myzen.co.uk>> > wrote:
>>
>> As always, as soon as I'd sent that I found an answer: someone who'd 
>> replaced "flaky" Belkin with Aten.
>
> I think they're probably all based on the same OEM chipsets, anyway. 
>
> I was quite into the KVM-over-IP versions a few years ago, and they certainly 
> all were. I'd find a near identical product (you could especially tell by the 
> web interface) from half a dozen or more manufacturers.
>
> Stroller.

Re: [gentoo-user] locale no longer recognised by Plasma and KDE apps?

[Mick]

On Saturday, 16 September 2017 13:27:18 BST Marc Joliet wrote:
> Am Mittwoch, 13. September 2017, 19:07:20 CEST schrieb Mick:
> > Another little problem I came across with Plasma is that neither the
> > keyboard, nor the spell checking respects the locale, L10N, or anything
> > else I have set up.  systemsettings5 shows en-GB as the selected language
> > and keyboard, but (I think) a US keyboard layout and spell checking
> > language is used instead.
> 
> I have a slightly different problem with recent Plasma versions, but I
> wonder if they're related:
> 
> Changing the spell checking language doesn't do anything, it sticks to
> whatever was selected to begin with, even though it *looks* like I changed
> the selection.  For example, if German is the initial selection, after
> changing to any English variant English-only words are still highlighted as
> incorrect.
> 
> I did just test changing the keyboard, though, and that still works (via the
> default Ctrl-Alt-k keybinding).

Ahh!  This is interesting.  It only showed US keyboard being available.  So I 
looked into systemsettings5 and I discovered only US keyboard was listed.  So, 
I added the UK keyboard and this seems to have fixed the keyboard problem.  
Thanks for the hint.


> > Is this another systemd-R-us imposition, or is there a way I can set it up
> > so that Plasma & friends respect the default environment settings?
> 
> I don't understand why you would think that to be the case, systemd also
> just uses (and controls, if you use localectl) the usual variables in /etc/
> locale.conf.
> 
> > $ env | grep LANG
> > LANG=en_GB.UTF8
> 
> For completeness, I've got:
> 
> % env | grep LANG
> LANG=de_DE.utf8
> LANGUAGE=de:en_GB
> 
> HTH

Where is the LANGUAGE variable expected/required?  I have not found it in the 
documentation.

-- 
Regards,
Mick

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

Re: [gentoo-user] [OT] Choice of KVM?

[Alan Mackenzie]

Hello, Peter.

On Sat, Sep 16, 2017 at 15:00:16 +0100, Peter Humphrey wrote:
> Hello list,

> I didn't know where else to ask this, or I'd have spared you the annoyance. 
> Apologies if needed.

> I need to replace a 4-port KVM switch by StarTech, which has failed twice - 
> that is, the original failed and its replacement has as well.

> Two makes present themselves: Aten and Belkin. Does anyone have an opinion 
> on which is better? They seem to have similar abililties and /modi 
> operandi/.

All I can say is that I bought an ATEN KVM box some months ago to help
in installing Gentoo on my new box.  It's V is two DVI connections, and
it also connects up audio.

It has performed flawlessly.  The only slight problem has been the
sluggishness in switching between machines - it takes well over a
second.

I have no experience with Belkin's KVMs.

> Many thanks.

> -- 
> Regards,
> Peter.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] thin-provisioning-tools - but I don't provision anything!!!!!

[Alan Mackenzie]

Hello, Alan.

On Sat, Sep 16, 2017 at 00:15:35 +0200, Alan McKinnon wrote:
> On 15/09/2017 23:43, Alan Mackenzie wrote:
> > On Fri, Sep 15, 2017 at 23:38:21 +0200, Marc Joliet wrote:
> >> Am Freitag, 15. September 2017, 23:15:05 CEST schrieb Alan Mackenzie:
> >>> Yes, but do I want it to go away?  What is it, what does it do?

> >>> OK, let's try emerge -s thin-provisioning-tools.  We get back only
> >>> patronising garbage, namely "A suite of tools for thin provisioning on
> >>> Linux" - well, duh!  Who write's this stuff?

> >>> So, WTF is thin provisioning?

> >> I'm tempted to ask whether google is down or something, but I'm tired and 
> >> waiting for 7z to finish so here you go anyway:

> > For me, google is permanently down.

> >> https://en.wikipedia.org/wiki/Thin_provisioning

> > Yes, I've read it, thanks.  My question above was somewhat rhetorical.

> >> I would say you probably don't need to care about it.

> > I do.  I need to spend time and effort removing it.  It sounds like
> > something only useful in servers, yet I have a desktop profile installed.

> > There's something not quite right, here.


> Reign in the paranoia there friend. This is Gentoo and you have choices.
> You are getting lvm because you elected to get it, it's set somewhere in
> your USE.

No, I actually use LVM to massage partition sizes, (but not for anything
else).

> What is LVM? A tool for managing disk volumes. If you don't know what it
> is, you probably don't need it.

On my last machine, I only used it once or twice (to increase partition
sizes), but without it I would have spent a lot of time creating
partitions, copying stuff across, and so on.  I might need it more on my
new machine, which has only 500Gb of SSD (as compared with 1Tb of HDD).

> What is thin-provisioning? A way to allocate space on your disks without
> actually using it until you put real data in. So a say 50G volume that
> is empty will consume no disk space (or maybe a few K in overhead). Sort
> of like sparse files for entire volumes.

Thanks.  It sounds like something which, if you don't know what it is,
you don't need.  And reading the Gentoo wiki article, it seems that there
are some gotchas associated with it.  I don't think the USE flag `thin'
should have been enabled by default.  I'm going to disable it, now I know
what it is.

What really got up my nose, as mentioned above, was doing an emerge -s on
thing-provisioning-tools and getting told it was "tools for thin
provisioning".  What really takes up time maintaining a computer, or
programming for that matter, is continually having to look somewhere else
for something.  Even though I doubt it was deliberately designed to
annoy, that emerge -s entry could hardly have been more annoying if
somebody had tried to make it so.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] [OT] Choice of KVM?

[Stroller]

> On 16 Sep 2017, at 15:19, Peter Humphrey  wrote:
> 
> As always, as soon as I'd sent that I found an answer: someone who'd 
> replaced "flaky" Belkin with Aten.

I think they're probably all based on the same OEM chipsets, anyway. 

I was quite into the KVM-over-IP versions a few years ago, and they certainly 
all were. I'd find a near identical product (you could especially tell by the 
web interface) from half a dozen or more manufacturers.

Stroller.

[gentoo-user] Re: Confirm unsubscribe from gentoo-user@lists.gentoo.org

[bic]

On Saturday, September 16, 2017 4:30:58 PM CEST gentoo-user
+h...@lists.gentoo.org wrote:
> Somebody (and we hope it was you) has requested that the email address
>  be removed from the list.
> 
> To confirm you want to do this, please send a message to
>  > which can usually be done simply by replying to this message. The subject
> and the body of the message can be anything.
> 
> After doing so, you should receive a reply informing you that the operation
> succeeded.
> 
> If you do not want to do this, simply ignore this message.


-- 
Jabber: bi...@autistici.org
Key fingerprint = DCBA CE20 0322 934F 0E3E  D20B DD13 1F6B 26AF 477B

Re: [gentoo-user] locale no longer recognised by Plasma and KDE apps?

[Daniel Frey]

On 09/16/2017 12:24 AM, Frank Steinmetzger wrote:


I’m on openrc, too, and my user details dialog only shows “New user”.
Neither my own account nor the guest account that I added a few days back
is visible. Clicking on the [+] at the bottom has no effect at all.



The machine I'm on right now is systemd, and I don't see a list of users 
in the User Details part of the control panel either. Maybe it's just a 
KDE thing?


Dan

Re: [gentoo-user] [OT] Choice of KVM?

[Peter Humphrey]

On Saturday, 16 September 2017 15:00:16 BST Peter Humphrey wrote:
> Hello list,
> 
> I didn't know where else to ask this, or I'd have spared you the
> annoyance. Apologies if needed.
> 
> I need to replace a 4-port KVM switch by StarTech, which has failed twice
> - that is, the original failed and its replacement has as well.
> 
> Two makes present themselves: Aten and Belkin. Does anyone have an opinion
> on which is better? They seem to have similar abililties and /modi
> operandi/.
> 
> Many thanks.

As always, as soon as I'd sent that I found an answer: someone who'd 
replaced "flaky" Belkin with Aten.

Sorry for the noise.

-- 
Regards,
Peter.

[gentoo-user] Fail2Ban vs SSHGuard? Comparison? What's the difference?

[Stroller]

Is anyone familiar enough with this subject to make a comparison between these 
two programs, please?

If I google Fail2Ban vs SSHGuard I get many hits saying "I use this one", but 
no-one saying why one might be better than the other.

So far I'm favouring SSHGuard, but mostly because the website looks prettier.

I want to be able to use passwords, so allowing logons only by public-key is no 
good (also would be nice to block failed IMAP connection attempts).

Thanks in advance for any thoughts. 

Stroller.

[gentoo-user] [OT] Choice of KVM?

[Peter Humphrey]

Hello list,

I didn't know where else to ask this, or I'd have spared you the annoyance. 
Apologies if needed.

I need to replace a 4-port KVM switch by StarTech, which has failed twice - 
that is, the original failed and its replacement has as well.

Two makes present themselves: Aten and Belkin. Does anyone have an opinion 
on which is better? They seem to have similar abililties and /modi 
operandi/.

Many thanks.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: [offtopic] Copy-On-Write ?

[Rich Freeman]

On Sat, Sep 16, 2017 at 8:06 AM, Kai Krakow  wrote:
>
> But I guess that btrfs doesn't use 10G sized extents? And I also guess,
> this is where autodefrag jumps in.
>

It definitely doesn't use 10G extents considering the chunks are only
1GB.  (For those who aren't aware, btrfs divides devices into chunks
which basically act like individual sub-devices to which operations
like mirroring/raid/etc are applied.  This is why you can change raid
modes on the fly - the operation takes effect on new chunks.  This
also allows clever things like a "RAID1" on 3x1TB disks to have 1.5TB
of useful space, because the chunks essentially balance themselves
across all three disks in pairs.  It also is what causes the infamous
issues when btrfs runs low on space - once the last chunk is allocated
it can become difficult to rebalance/consolidate the remaining space.)

I couldn't actually find any info on default extent size.  I did find
a 128MB example in the docs, so presumably that isn't an unusual size.
So, the 1MB example would probably still work.  Obviously if an entire
extent becomes obsolete it will lose its reference count and become
free.

Defrag was definitely intended to deal with this.  I haven't looked at
the state of it in ages, when I stopped using it due to a bug and some
limitations.  The main limitation being that defrag at least used to
be over-zealous.  Not only would it free up the 1MB of wasted space,
as in this example, but if that 1GB file had a reflink clone it would
go ahead and split it into two duplicate 1GB extents.  I believe that
dedup would do the reverse of this.  Getting both to work together
"the right way" didn't seem possible the last time I looked into it,
but if that has changed I'm interested.

Granted, I've been moving away from btrfs lately, due to the fact that
it just hasn't matured as I originally thought it would.  I really
love features like reflinks, but it has been years since it was
"almost ready" and it still tends to eat data.  For the moment I'm
relying more on zfs.  I'd love to switch back if they ever pull things
together.  The other filesystem I'm eyeing with interest is cephfs,
but that still is slightly immature (on-disk checksums were only just
added), and it has a bit of overhead until you get into fairly large
arrays.  Cheap arm-based OSD options seem to be fairly RAM-starved at
the moment as well given the ceph recommendation of 1GB/TB.  arm64
still seems to be slow to catch on, let alone cheap boards with 4-16GB
of RAM.

-- 
Rich

Re: [gentoo-user] locale no longer recognised by Plasma and KDE apps?

[Marc Joliet]

Am Mittwoch, 13. September 2017, 19:07:20 CEST schrieb Mick:
> Another little problem I came across with Plasma is that neither the
> keyboard, nor the spell checking respects the locale, L10N, or anything
> else I have set up.  systemsettings5 shows en-GB as the selected language
> and keyboard, but (I think) a US keyboard layout and spell checking
> language is used instead.

I have a slightly different problem with recent Plasma versions, but I wonder 
if they're related:

Changing the spell checking language doesn't do anything, it sticks to 
whatever was selected to begin with, even though it *looks* like I changed the 
selection.  For example, if German is the initial selection, after changing to 
any English variant English-only words are still highlighted as incorrect.

I did just test changing the keyboard, though, and that still works (via the 
default Ctrl-Alt-k keybinding).

> Is this another systemd-R-us imposition, or is there a way I can set it up
> so that Plasma & friends respect the default environment settings?

I don't understand why you would think that to be the case, systemd also just 
uses (and controls, if you use localectl) the usual variables in /etc/
locale.conf.

> $ env | grep LANG
> LANG=en_GB.UTF8

For completeness, I've got:

% env | grep LANG
LANG=de_DE.utf8
LANGUAGE=de:en_GB

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.

[gentoo-user] Re: [offtopic] Copy-On-Write ?

[Kai Krakow]

Am Fri, 15 Sep 2017 14:28:49 -0400
schrieb Rich Freeman :

> On Fri, Sep 8, 2017 at 3:16 PM, Kai Krakow 
> wrote:
> >
> > At least in btrfs there's also a caveat that the original extents
> > may not actually be split and the split extents share parts of the
> > original extent. That means, if you delete the original later, the
> > copy will occupy more space than expected until you defragment the
> > file: 
> 
> True, but keep in mind that this applies in general in btrfs to any
> kind of modification to a file.  If you modify 1MB in the middle of a
> 10GB file on ext4 you end up it taking up 10GB of space.  If you do
> the same thing in btrfs you'll probably end up with the file taking up
> 10.001GB.  Since btrfs doesn't overwrite files in-place it will
> typically allocate a new extent for the additional 1MB, and the
> original content at that position within the file is still on disk in
> the original extent.  It works a bit like a log-based filesystem in
> this regard (which is also effectively copy on write).

Good point, this makes sense. I never thought about that.

But I guess that btrfs doesn't use 10G sized extents? And I also guess,
this is where autodefrag jumps in.


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] locale no longer recognised by Plasma and KDE apps?

[Mick]

On Saturday, 16 September 2017 08:56:34 BST Peter Humphrey wrote:
> On Saturday, 16 September 2017 08:24:33 BST Frank Steinmetzger wrote:
> > I’m on openrc, too, and my user details dialog only shows “New user”.
> > Neither my own account nor the guest account that I added a few days back
> > is visible. Clicking on the [+] at the bottom has no effect at all.
> > 
> > Starting system settings from the terminal prints one line:
> > log_user_manager: "org.freedesktop.DBus.Error.ServiceUnknown" "The name
> > org.freedesktop.login1 was not provided by any .service files"
> > Not sure though whether that’s related.

I am not getting any of this in konsole.  systemsettings5 starts without any 
funfair.


> It certainly sounds likely. Do you start dbus in the default run level?
> 
> # rc-update -s -v | grep dbus
>  dbus |  default
> 
> Aren't *.service files part of systemd? I have none of them here. I wonder
> why your system is looking for one.

Thanks for this Peter, I just discovered on this PC I had not added dbus in 
the default run level.  Interestingly, dbus *is* running all the same:

# rc-update -s -v | grep dbus
 dbus |

# ps axf | grep dbus
 1701 ?Ss 0:00 /usr/bin/dbus-daemon --system
 2763 ?S  0:00 dbus-launch --autolaunch 
bea9f7f8958e4471f4c1d45f549ae52c --binary-syntax --close-stderr
 2764 ?Ss 0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-
address 7 --session
 3013 ?S  0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-
session
 3014 ?Ss 0:01 /usr/bin/dbus-daemon --fork --print-pid 5 --print-
address 15 --session
 3849 pts/2S+ 0:00  \_ grep --colour=auto dbus

So, something must be starting it - probably kdestart/plasmastart or whatever 
sddm is running to start the plasma session.
-- 
Regards,
Mick

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

Re: [gentoo-user] Dual booting with Windows 10

[taii...@gmx.com]

On 09/15/2017 05:03 AM, Radoje Stojisic wrote:


Hi all,

I am interested in doing something too. Do you talk about GPU 
Pass-through? Few months ago I wanted to try it myself but I own a 
Ryzen 1800x and just one GPU. Is there a way with only one GPU?

I am always willing to assist with complex technical problems.

Or do I really need 2GPUs and 2 Keyboard/Mouse?
Yeah you do as it is very difficult to re-map the BAR's of an an in-use 
graphics device.
Obviously one can use a single keyboard and mouse with a KVM, but the 
multi GPU part is mandatory.


You can buy a video card that doesn't need an additional power 
connection for only $30 or so, plus if you only have one USB controller 
you would need a USB PCI-e card one for $20 - TOTAL $50 very affordable.

Re: [gentoo-user] thin-provisioning-tools - but I don't provision anything!!!!!

[Peter Humphrey]

On Friday, 15 September 2017 23:30:07 BST Daniel Campbell wrote:

> If you have app-portage/gentoolkit (I highly recommend it) you can run
> `equery d sys-block/thin-provisioning-tools` to find what's pulling it
> in. It's probably lvm2, which is expected if you use LVM for anything.
> If you don't have any need for it:
> 
> * Add `USE="-lvm"` to make.conf to ensure you don't get LVM through IUSE
> * Add `sys-fs/lvm2` to package.mask, but realize you may lose partial
> functionality with some things, like net-fs/nfs-utils NFS v4.1 support.
> * emerge --changed-use --ask @world
> * emerge --ask --depclean
> 
> or
> 
> * Put `sys-fs/lvm2 -thin` in package.use, run `emerge --changed-use
> --ask @world`, and go about your day.

I just have -thin in make.conf. It's still there because I haven't got round 
to removing it since building this box 18 months ago. The old box had LVM on 
twin disks and I didn't want thin provisioning, whereas this one just has a 
single SSD.

-- 
Regards,
Peter.

Re: [gentoo-user] locale no longer recognised by Plasma and KDE apps?

[Peter Humphrey]

On Saturday, 16 September 2017 08:24:33 BST Frank Steinmetzger wrote:

> I’m on openrc, too, and my user details dialog only shows “New user”.
> Neither my own account nor the guest account that I added a few days back
> is visible. Clicking on the [+] at the bottom has no effect at all.
> 
> Starting system settings from the terminal prints one line:
> log_user_manager: "org.freedesktop.DBus.Error.ServiceUnknown" "The name
> org.freedesktop.login1 was not provided by any .service files"
> Not sure though whether that’s related.

It certainly sounds likely. Do you start dbus in the default run level?

# rc-update -s -v | grep dbus
 dbus |  default   

Aren't *.service files part of systemd? I have none of them here. I wonder 
why your system is looking for one.

-- 
Regards,
Peter.

Re: [gentoo-user] locale no longer recognised by Plasma and KDE apps?

[Frank Steinmetzger]

On Thu, Sep 14, 2017 at 02:17:07PM +0100, Peter Humphrey wrote:

> > > > systemsettings5 only allows one to add a user. Existing user
> > > > accounts are not listed.
> > > 
> > > Now that's definitely wrong. I have no users other than myself, but I do
> > > appear in the user manager. I do have to give the root password to save
> > > any changes I make, though, which is only natural.
> > 
> > […] All I could do is add a new user, which is not something I would
> > like to do.
> >
> > Can you please confirm if you are running systemd with your Plasma
> > installation?
> 
> No, just good old openrc.

I’m on openrc, too, and my user details dialog only shows “New user”.
Neither my own account nor the guest account that I added a few days back
is visible. Clicking on the [+] at the bottom has no effect at all.

Starting system settings from the terminal prints one line:
log_user_manager: "org.freedesktop.DBus.Error.ServiceUnknown" "The name
org.freedesktop.login1 was not provided by any .service files"
Not sure though whether that’s related.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

“Wow!  That lightning sounded clo... zzzit!” -- NO CARRIER --


signature.asc
Description: Digital signature

Re: [gentoo-user] virtualbox: no x-server after kernel upgrade to 4.12.12-gentoo [SOLVED]

[Alexander Puchmayr]

Am Freitag, 15. September 2017, 20:35:03 schrieb Alexander Kapshuk:
> On Fri, Sep 15, 2017 at 5:47 PM, Alexander Puchmayr 
 wrote:
> [list with log dumps cutted]
> > Obviously, something is going terribly wrong here, and I'm getting stuck
> > as I
> > do not have any Idea where to start. The only thing that changed is a
> > kernel
> > upgrade and a rebuild of the virtual box modules.
> > 
> > Any ideas?
> > 
> > Thanks in advance,
> > 
> > Alex
> 
> The Gentoo wiki article referenced below emphasizes the fact that certain
> kernel config options need enabling in order to have proper hardware
> emulation. So you want to make sure you have those enabled in your kernel
> config. Then take it from there.
> 
> https://wiki.gentoo.org/wiki/VirtualBox
> 

Thanks for your hint, the kernel config was as it should be (except that I used 
modules wherever possible).  

My assumption was that the kernel frame buffer device and X driver conflict and 
the X server does not load because the kernel frame buffer driver was active. 
So, I removed the kernel driver by blacklisting vboxvideo

$ cat /etc/modprobe.d/blacklist.conf
blacklist vboxvideo
$ genkernel initramfs
[...]
$ reboot

After reboot: sddm showed a login screen, X was working (with VboxVideo 
driver), I could log in successfully.

Problem solved :-)

Thanks to all who spent a thought on this!

Regards
Alex

PS: The question, why a framebuffer device for virtualbox is automatically 
created just to cause a conflict with X later on, still remains. Do other 
installations have the same problem?