[gentoo-user] Re: CIFS mounts started misbehaving

[Kai Krakow]

Am Mon, 06 Mar 2017 19:01:57 +
schrieb "J. Roeleveld" :

> On March 6, 2017 5:14:39 PM GMT+01:00, Grant Edwards
>  wrote:
> >On 2017-03-06, Kai Krakow  wrote:
> >  
>  [...]  
> >and  
>  [...]  
> >>
> >> Did something on the Windows side change?  
> >
> >Probaby, but I've learned not to ask questions like that.  They never
> >get answered, and it just causes problems when it is revealed that
> >the client having problems is a Linux machine.
> >  
> >> Maybe force Windows down to a lower SMB version or reduce/disable
> >> SMB client side caching?  
> 
> Windows sharing is designed as a 'link when used' option. Not as a
> permanent mount like Linix treats it.
> 
> Even 'mounting' in Windows doesn't mean the share is actually
> accessed.
> 
> A windows CIFS server will not be reliable enough for long term
> mounting. With Samba, it does work more reliable. (In my experience)
> 
> For this reason, I use KDE/Dolphin to access CIFS shares. It is
> closer to how Windows expects the shares to be treated.

Then it may help to use automount with a somewhat low timeout, maybe
also setup cachefilesd and mount with fsc option. This is how I use my
office shares on a 2012 R2 server via VPN.

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: CIFS mounts started misbehaving

[Marc Joliet]

On Dienstag, 7. März 2017 00:12:06 CET Grant Edwards wrote:
> On 2017-03-03, Grant Edwards  wrote:
> > For the past 10-15 [years], I've been mounting a handfull of
> > directories that reside on a Windows server, and it's always worked
> > find.
> > 
> > About a week ago, they started acting oddly.  They all mount fine, and
> > work as usual as long as you keep using them.  AFAICT, if they sit
> > idle for "a while" (tens of minutes, maybe an hour), they freeze up.
> 
> It finally dawned on me that I had changed something.
> 
> It's a kernel 4.9 problem.
> 
> I had built and installed a gentoo-sources 4.9.6-r1 kernel about a
> month ago, but didn't update the grub configuration and reboot until
> two weeks ago.
> 
> Rebooting with the 4.4.39 kernel fixes the problem.
> 
> [I also tried just rebooting the 4.9.4 kernel, but that didn't help.]
> 
> The configuration of the 4.9.4 kernel is as close to that of the
> 4.4.39 as I can get.
> 
> I guess I'll have to stick with the 4.4 series until this gets fixed.

I'm glad you found the source of the problem and a workaround.  However, the 
4.9 series is now at 4.9.13.  Have you tried that, too?

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] rotating backup script

[Jean-Christophe Bach]

Hello,

> I was looking at this rotating backup script
> 
> source:
> https://community.spiceworks.com/topic/34970-how-to-create-rotating-backups-of-files
> 
> --backup script
> BACKUPDIR=`date +%A`
> OPTS="--force --ignore-errors --delete-excluded --exclude-from=$EXCLUDES 
>   --delete --backup --backup-dir=/$BACKUPDIR -a"
> 
> export PATH=$PATH:/bin:/usr/bin:/usr/local/bin
> 
> # the following line clears the last weeks incremental directory
> [ -d $HOME/emptydir ] || mkdir $HOME/emptydir
> rsync --delete -a $HOME/emptydir/ $BSERVER::$USER/$BACKUPDIR/
> rmdir $HOME/emptydir
> 
> # now the actual transfer
> rsync $OPTS $BDIR $BSERVER::$USER/current
> ---end backup script
> 
> Can anybody explain why they they "...clear the last weeks incremental 
> directory"?

Probably because BACKUPDIR is set to the name of the day (`date +`A`).
Today is Tuesday and a backup is done, next week the backup will be
overwritten because BACKUPDIR will also be Tuesday. Therefore there will
only be 7 directories.

> Doesn't "rsync --deleate" option take take care of this?

--delete removes extraneous files. Combined with the previous thing, it
ensures the backup rotation.

> Does it have something to do with Windows? 

Hu? What is Windows? I do not know what are those alternative OSs ;)

Regards,

JC


signature.asc
Description: PGP signature

[gentoo-user] rotating backup script

[thelma]

I was looking at this rotating backup script

source:
https://community.spiceworks.com/topic/34970-how-to-create-rotating-backups-of-files

--backup script
BACKUPDIR=`date +%A`
OPTS="--force --ignore-errors --delete-excluded --exclude-from=$EXCLUDES 
  --delete --backup --backup-dir=/$BACKUPDIR -a"

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin

# the following line clears the last weeks incremental directory
[ -d $HOME/emptydir ] || mkdir $HOME/emptydir
rsync --delete -a $HOME/emptydir/ $BSERVER::$USER/$BACKUPDIR/
rmdir $HOME/emptydir

# now the actual transfer
rsync $OPTS $BDIR $BSERVER::$USER/current
---end backup script

Can anybody explain why they they "...clear the last weeks incremental 
directory"?

Doesn't "rsync --deleate" option take take care of this?

Does it have something to do with Windows? 

-- 
Thelma

Re: [gentoo-user] Helvetica fonts

[thelma]

On 03/06/2017 02:42 PM, David W Noon wrote:
> On Mon, 6 Mar 2017 13:50:33 -0700, Thelma (the...@sys-concept.com) wrote
> about "Re: [gentoo-user] Helvetica fonts" (in
> <169d7ee4-a369-de54-3f4c-daafc5474...@sys-concept.com>):
> 
>> On 03/06/2017 01:33 PM, David W Noon wrote:
>>> On Mon, 6 Mar 2017 12:27:23 -0700, Thelma (the...@sys-concept.com) wrote
>>> about "[gentoo-user] Helvetica fonts" (in
>>> <527dc91e-d02e-4dc8-8f22-d24d16018...@sys-concept.com>):
>>>
 Which package contain "Helvetica" font?
>>>
>>> app-text/htmldoc
>>
>> No, "htmldoc" doesn't have any helvetica fonts
> 
> Actually, it does. Here is an extract from the qlist for that package:
> 
>  /usr/share/htmldoc/fonts/Helvetica.afm
>  /usr/share/htmldoc/fonts/Helvetica-Bold.afm
>  /usr/share/htmldoc/fonts/Helvetica-BoldOblique.afm
>  /usr/share/htmldoc/fonts/Helvetica-BoldOblique.pfa
>  /usr/share/htmldoc/fonts/Helvetica-Bold.pfa
>  /usr/share/htmldoc/fonts/Helvetica-Oblique.afm
>  /usr/share/htmldoc/fonts/Helvetica-Oblique.pfa
>  /usr/share/htmldoc/fonts/Helvetica.pfa
> 
>> flpsed - is hard coded use: FL_HELVETICA
> 
> That would seem to be a particular recension of Helvetica. The one
> supplied by htmldoc is the Adobe original. Note that Helvetica is also
> called Swiss.

OK, you proved me wrong :-/
I've emerge htmldoc copied their fonts to /usr/share/fonts/Helvetica/
unmerged htmldoc
run: fc-cache -fv

But the fonts in "flpsed" are still same looking (not impressive).

I've the following fonts installed:
ll /usr/share/fonts/Helvetica/
-rw-r--r-- 1 root root 31741 Mar  6 16:24 Helvetica.afm
-rw-r--r-- 1 root root 31586 Mar  6 16:24 Helvetica-Bold.afm
-rw-r--r-- 1 root root 31896 Mar  6 16:24 Helvetica-BoldOblique.afm
-rw-r--r-- 1 root root 77039 Mar  6 16:24 Helvetica-BoldOblique.pfa
-rw-r--r-- 1 root root 70803 Mar  6 16:24 Helvetica-Bold.pfa
-rw-r--r-- 1 root root 39520 Mar  6 13:04 'Helvetica Neu Bold.ttf'
-rw-r--r-- 1 root root 39520 Mar  6 13:04 HelveticaNeueBd.ttf
-rw-r--r-- 1 root root 38016 Mar  6 13:04 'HelveticaNeue BlackCond.ttf'
-rw-r--r-- 1 root root 39568 Mar  6 13:04 HelveticaNeueHv.ttf
-rw-r--r-- 1 root root 43148 Mar  6 13:04 HelveticaNeueIt.ttf
-rw-r--r-- 1 root root 40104 Mar  6 13:04 'HelveticaNeue Light.ttf'
-rw-r--r-- 1 root root 40104 Mar  6 13:04 HelveticaNeueLt.ttf
-rw-r--r-- 1 root root 39656 Mar  6 13:04 'HelveticaNeue Medium.ttf'
-rw-r--r-- 1 root root 39656 Mar  6 13:04 HelveticaNeueMed.ttf
-rw-r--r-- 1 root root 40144 Mar  6 13:04 'HelveticaNeue Thin.ttf'
-rw-r--r-- 1 root root 41180 Mar  6 13:04 HelveticaNeue.ttf
-rw-r--r-- 1 root root 32044 Mar  6 13:56 helvetica-normal-58bdcca3a92e8.ttf
-rw-r--r-- 1 root root 32097 Mar  6 16:24 Helvetica-Oblique.afm
-rw-r--r-- 1 root root 75595 Mar  6 16:24 Helvetica-Oblique.pfa
-rw-r--r-- 1 root root 70952 Mar  6 16:24 Helvetica.pfa

So I don't know what fonts it is looking for.

--
Thelma
 

[gentoo-user] Re: CIFS mounts started misbehaving

[Grant Edwards]

On 2017-03-03, Grant Edwards  wrote:

> For the past 10-15 [years], I've been mounting a handfull of
> directories that reside on a Windows server, and it's always worked
> find.
>
> About a week ago, they started acting oddly.  They all mount fine, and
> work as usual as long as you keep using them.  AFAICT, if they sit
> idle for "a while" (tens of minutes, maybe an hour), they freeze up.

It finally dawned on me that I had changed something.

It's a kernel 4.9 problem.

I had built and installed a gentoo-sources 4.9.6-r1 kernel about a
month ago, but didn't update the grub configuration and reboot until
two weeks ago.

Rebooting with the 4.4.39 kernel fixes the problem.

[I also tried just rebooting the 4.9.4 kernel, but that didn't help.]

The configuration of the 4.9.4 kernel is as close to that of the
4.4.39 as I can get.

I guess I'll have to stick with the 4.4 series until this gets fixed.

-- 
Grant Edwards   grant.b.edwardsYow! Now we can become
  at   alcoholics!
  gmail.com

Re: [gentoo-user] Rear & Genkernel

[Alan McKinnon]

On 06/03/2017 23:55, White, Phil wrote:
> Hi,
> 
> I'm not sure if this needs submitting as a bug, or if I just need a
> little help in configuring...
> 
> I have set up a new install of Gentoo. I use genkernel to create my
> kernel and initrd.
> The resulting /boot directory gives:
>   kernel-genkernel-x86-4.9.6-gentoo-r1
> 
> My chost is i686-pc-linux-gnu.
> 
> Now, I also have installed rear (relax-and-recover) v2, from git
> (app-backup/rear is 1.17.1)
> 
> Problem: rear is looking for a kernel, and it expects it to be named:
>   kernel-genkernel-i686-4.9.6-gentoo-r1
> Since the name doesn't match, it bails out with an error. (This only
> fails with my i686 machine. Running the same configuration on a 64-bit
> machine works fine)
> 
> Question: How am I going to fix this? I don't want to hard code anything
> in the config file, as this will break when I update the kernel... Is
> this a 'bug'?


Please clarify what version of rear has this problem, and how you
installed it.

Either way, from the problem description one can see that rear needs
patching, however:

If it was installed by ortage from an ebuild, then you have a bug to be
reported to b.g.o.

If you installed from git outside of portage, the you get to patch rear
yourself

Or, perhaps a third option. Does rear have a config file where you can
define the naming template for the kernel used? (I don't use rear and
can't be bothered googling it, the idea just occurred to me)


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

[gentoo-user] Re: GUI-less (non-dbus) virt-manager (to run Tails in Gentoo)

[Miroslav Rovis]

This email will be about some good results that I have obtained in this
non-dbus virt-manager matter, and at least one snag left to solve...

I have made a lot of progress in using non-dbus virt-manager recently.

I hope some readers might be interested in these not very usual, except
in Gentoo, feats.

Let me remind you:

On 170114-12:48+0100, Miroslav Rovis wrote:
> Hi!
> 
> This is my installation of the package virt-manager:
> 
> # equery l virt-manager
>  * Searching for virt-manager ...
> [IP-] [  ] app-emulation/virt-manager-1.4.0-r2:0
> #
The above is still the case. And so is the below.

> # emerge -pv virt-manager
> 
...
> 
> /usr/bin/virt-clone
> /usr/bin/virt-convert
> /usr/bin/virt-install
> /usr/bin/virt-xml
> 
> While at the list of files, pls. notice that there is no executable named
> 'virt-manager' in my system's virt-manager install:
...

This is what I thought that I needed to do at the onset:
> 
> So I guess, to get Tails installed, the way I will need to follow:
> 
> https://tails.boum.org/doc/advanced_topics/virtualization/virt-manager/index.en.html

But there is now the better debian than the systemDestructed Debian,
which is Devuan, and there is now Heads (based on Devuan) instead of
Tails (based on Debian):

https://heads.dyne.org/about.html
or
http://fz474h2o46o2u7xj.onion/about.html

And, as far as Tails, I can use it, although as of this time still only
in pure Qemu (just a little is still missing for full Libvirt deployment
under sound control of grsecurity RBAC policies... more below about
that):
https://www.croatiafidelis.hr/foss/cap/cap-161015-qemu-devuan/qemu-devuan-10.php
(and the successive page)

This was wrong, that's for developers
> So, the mailing list:
> 
> https://www.redhat.com/mailman/listinfo/virt-tools-list
> 
there's users list instead:
https://www.redhat.com/mailman/listinfo/libvirt-users

But I first need to complete setting up the grsecurity RBAC policies for
Libvirt:

Libvirt virtualization policies
https://forums.grsecurity.net/viewtopic.php?f=5=4675

which I might be at an end of (that took time! but it feels
rewarding)...

All of that I have successfully managed to do without dbus...

Or d-bus, like in the comparison table of init systems:

https://wiki.gentoo.org/wiki/Comparison_of_init_systems

Which I hope is slowly spreading from Gentoo into other true-unix FOSS,
the sans-dbus OpenRC...

But I would need time to see, say, how far Devuan has reached in
implementing OpenRC, as they planned...

(I'm not a dev, I'm only yet struggling to become a good
tester for projects that I believe in...)

I have also hit a snag... see the last post at:

Whonix on Gentoo issues
https://forums.whonix.org/t/whonix-on-gentoo-issues/3188/17
where find (pasting:

(virt-viewer:9916): GSpice-CRITICAL **: egl init failed: cannot create
EGL context

and more. That's basically, my virt-manager, virt-viewer and spice, and
spice-gtk and xf86-video-qxl have some issues, and when virt-viewer
starts, the spice client can't get the egl context, which I have come to
understand is the... keyboard and the mouse...

In slow time, if anybody has any advice about this matter, I'll be
greatful!

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature

Re: [gentoo-user] Helvetica fonts

[David W Noon]

On Mon, 6 Mar 2017 14:25:49 -0700, Thelma (the...@sys-concept.com) wrote
about "Re: [gentoo-user] Helvetica fonts" (in
<9e705dc8-2c68-1f9b-d690-3171da36b...@sys-concept.com>):

> According to this post:
> http://www.flpsed.org/lists/flpsed/0018.html

If you read that message you will see that you do *NOT* want a font
called "helvetica".

Instead, you want a font called "Helvetica". Do you see the difference?
Welcome to UNIX. ... :-)

> It is hardcoded with "FL_HELVETICA"; what "FL" stands for?

That is a mnemonic prefix for a C manifest constant. Unfortunately, it
is only mnemonic to the developers of flpsed; it means nothing to the
rest of us.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 




signature.asc
Description: OpenPGP digital signature

[gentoo-user] Rear & Genkernel

[White, Phil]

Hi,

I'm not sure if this needs submitting as a bug, or if I just need a little
help in configuring...

I have set up a new install of Gentoo. I use genkernel to create my kernel
and initrd.
The resulting /boot directory gives:
  kernel-genkernel-x86-4.9.6-gentoo-r1

My chost is i686-pc-linux-gnu.

Now, I also have installed rear (relax-and-recover) v2, from git
(app-backup/rear is 1.17.1)

Problem: rear is looking for a kernel, and it expects it to be named:
  kernel-genkernel-i686-4.9.6-gentoo-r1
Since the name doesn't match, it bails out with an error. (This only fails
with my i686 machine. Running the same configuration on a 64-bit machine
works fine)

Question: How am I going to fix this? I don't want to hard code anything in
the config file, as this will break when I update the kernel... Is this a
'bug'?

Thanks in advance,

Phil

Re: [gentoo-user] Helvetica fonts

[David W Noon]

On Mon, 6 Mar 2017 13:50:33 -0700, Thelma (the...@sys-concept.com) wrote
about "Re: [gentoo-user] Helvetica fonts" (in
<169d7ee4-a369-de54-3f4c-daafc5474...@sys-concept.com>):

> On 03/06/2017 01:33 PM, David W Noon wrote:
>> On Mon, 6 Mar 2017 12:27:23 -0700, Thelma (the...@sys-concept.com) wrote
>> about "[gentoo-user] Helvetica fonts" (in
>> <527dc91e-d02e-4dc8-8f22-d24d16018...@sys-concept.com>):
>>
>>> Which package contain "Helvetica" font?
>>
>> app-text/htmldoc
> 
> No, "htmldoc" doesn't have any helvetica fonts

Actually, it does. Here is an extract from the qlist for that package:

 /usr/share/htmldoc/fonts/Helvetica.afm
 /usr/share/htmldoc/fonts/Helvetica-Bold.afm
 /usr/share/htmldoc/fonts/Helvetica-BoldOblique.afm
 /usr/share/htmldoc/fonts/Helvetica-BoldOblique.pfa
 /usr/share/htmldoc/fonts/Helvetica-Bold.pfa
 /usr/share/htmldoc/fonts/Helvetica-Oblique.afm
 /usr/share/htmldoc/fonts/Helvetica-Oblique.pfa
 /usr/share/htmldoc/fonts/Helvetica.pfa

> flpsed - is hard coded use: FL_HELVETICA

That would seem to be a particular recension of Helvetica. The one
supplied by htmldoc is the Adobe original. Note that Helvetica is also
called Swiss.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Helvetica fonts

[thelma]

On 03/06/2017 02:10 PM, Mick wrote:
> On Monday 06 Mar 2017 13:50:33 the...@sys-concept.com wrote:
>> On 03/06/2017 01:33 PM, David W Noon wrote:
>>> On Mon, 6 Mar 2017 12:27:23 -0700, Thelma (the...@sys-concept.com) wrote
>>> about "[gentoo-user] Helvetica fonts" (in
>>>
>>> <527dc91e-d02e-4dc8-8f22-d24d16018...@sys-concept.com>):
 Which package contain "Helvetica" font?
>>>
>>> app-text/htmldoc
>>
>> No, "htmldoc" doesn't have any helvetica fonts
>> flpsed - is hard coded use: FL_HELVETICA
>>
>> --
>> Thelma
> 
> According to:
> 
> find /usr/share/fonts/ -iname helv*
> 
> /usr/share/fonts/100dpi/ and /usr/share/fonts/75dpi seem to contain hevetica.

Yes, I have them installed, so I don't know why "flpsed" is showing such
an ugly fonts.
According to this post:
http://www.flpsed.org/lists/flpsed/0018.html

It is hardcoded with "FL_HELVETICA"; what "FL" stands for?

In the past installing "media-fonts/liberation-fonts" which I have
solved the problem, but it is not working now.

--
Thelma

Re: [gentoo-user] Helvetica fonts

[Mick]

On Monday 06 Mar 2017 13:50:33 the...@sys-concept.com wrote:
> On 03/06/2017 01:33 PM, David W Noon wrote:
> > On Mon, 6 Mar 2017 12:27:23 -0700, Thelma (the...@sys-concept.com) wrote
> > about "[gentoo-user] Helvetica fonts" (in
> > 
> > <527dc91e-d02e-4dc8-8f22-d24d16018...@sys-concept.com>):
> >> Which package contain "Helvetica" font?
> > 
> > app-text/htmldoc
> 
> No, "htmldoc" doesn't have any helvetica fonts
> flpsed - is hard coded use: FL_HELVETICA
> 
> --
> Thelma

According to:

find /usr/share/fonts/ -iname helv*

/usr/share/fonts/100dpi/ and /usr/share/fonts/75dpi seem to contain hevetica.
-- 
Regards,
Mick

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

Re: [gentoo-user] Helvetica fonts

[Corbin Bird]

On 03/06/2017 01:27 PM, the...@sys-concept.com wrote:
> Which package contain "Helvetica" font?
> 
> I'm using "flpsed" and apparently it is using Helvetica font, which
> "eselect fontconfig list" is not showing anything that resemble "helvet"
> "eix helvet" is not showing anything either.
> 
> The fonts in "flpsed" display are very rugged/pixelated, it is hard to
> look at them.
> 

This font package works for Helvetica deps in Mozilla / Firefox && CUPS.

"media-fonts/liberation-fonts"


Reference Link :
https://packages.gentoo.org/packages/media-fonts/liberation-fonts


Corbin

Re: [gentoo-user] Helvetica fonts

[thelma]

On 03/06/2017 01:33 PM, David W Noon wrote:
> On Mon, 6 Mar 2017 12:27:23 -0700, Thelma (the...@sys-concept.com) wrote
> about "[gentoo-user] Helvetica fonts" (in
> <527dc91e-d02e-4dc8-8f22-d24d16018...@sys-concept.com>):
> 
>> Which package contain "Helvetica" font?
> 
> app-text/htmldoc

No, "htmldoc" doesn't have any helvetica fonts
flpsed - is hard coded use: FL_HELVETICA

--
Thelma

Re: [gentoo-user] Helvetica fonts

[David W Noon]

On Mon, 6 Mar 2017 12:27:23 -0700, Thelma (the...@sys-concept.com) wrote
about "[gentoo-user] Helvetica fonts" (in
<527dc91e-d02e-4dc8-8f22-d24d16018...@sys-concept.com>):

> Which package contain "Helvetica" font?

app-text/htmldoc
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] SHA-1 has just been broken

[Rich Freeman]

On Mon, Mar 6, 2017 at 2:59 PM, Andrew Savchenko  wrote:
> On Thu, 2 Mar 2017 19:04:06 -0500 Rich Freeman wrote:
>>
>> Huh?  I thought protection against DMA attacks was half the reason for
>> an IOMMU in the first place.
>>
>> https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit
>
> Even the page you cited contains:
> ``Some units also provide memory protection from faulty or
> malicious devices.''
>
> Please note the word "some" here.
>
> IOMMU was created to restrict OS access to devices (and bring
> desired guest VM direct hw access when needed). While it may be
> used the other way around — to protect OS from device — it usually
> don't work this way, not every IOMMU even supports this.

How can it be possible to bring VM guests direct hw access without
providing protection of the OS from devices?

They use the same mechanism.  The driver in the VM tells the card to
write to address XYZ, not knowing that address XYZ in the guest is
different from address XYZ in the host.  The host programs the IOMMU
to remap the device access to the correct address.  The same mechanism
would let the host remap device DMA to anywhere, or nowhere.

Restricting OS access to devices seems odd unless you're talking about
something like a phone with a second protected CPU.  I imagine most
CPUs treat IO access as a privileged operation, and certainly x86
does.  So, if a process attempts to write to an IO port it will be
interrupted and the OS can block the access.

>
> If we'll look further, IOMMU bypass is a part of normal operation
> of many device drivers:
> https://lists.gt.net/linux/kernel/365102

Yeah, I wasn't familiar with how poorly it is actually implemented,
and obviously the IOMMU is only as good as its programming.

> And the funniest stuff: even if IOMMU can be and is configured to
> sandbox malicious devices, it can be easily bypassed in most real
> world implementations:
> https://hal.archives-ouvertes.fr/hal-01419962/document

This is just an exploit, and in this case the IOMMU wasn't configured
to sandbox the device at all.  If it were configured with minimal
access it certainly wouldn't have write access to the IOMMU
configuration.

> So relying on IOMMU to protect from malicious devices is even more
> naive than relying on SHA1 for crypto integrity needs.

So, I think we're conflating poor implementation with a flawed algorithm.

SHA1 is fundamentally insecure and there is nothing you can do to make
it more secure without making it something other than SHA1.

IOMMU is more of a concept, but I suspect that much of the hardware in
actual use probably works just fine, but nobody spends much time
ensuring that Linux actually secures it.  Tighter controls around the
software would make it secure.

This seems a bit like saying that the concept of process memory
protection is flawed because at various points in time some versions
of Linux have had bugs that allow processes to modify memory they
shouldn't be able to modify.  The concept is completely sound, but the
implementation is imperfect.  I think the main reason that nobody
tolerates sloppy implementation of memory protection is that a lot of
software is written in C and if memory protection doesn't work it is
only a matter of time before the host is crashing, especially for a
software developer.  On the other hand, most devices aren't designed
with so many bugs so by the time you're actually plugging cards into
PCs they're not going to be randomly accessing RAM, and it is a lot
harder to get a device to write to random RAM locations than it is to
have a pointer error in your C code unless you're actually developing
a device driver (and if you have a bug in a device driver you could
very well have programmed the IOMMU to let the device write to the
wrong RAM anyway depending on where the error lies).

But, sure, I'm perfectly happy to accept your assertion that device
drivers today tend to open gaping holes in the IOMMU making their
security unreliable.  Linux namespaces are in a similar state,
eventually they should become secure but right now the sense is that
they have exploitable flaws.

-- 
Rich

Re: [gentoo-user] SHA-1 has just been broken

[Andrew Savchenko]

On Fri, 3 Mar 2017 08:48:30 -0500 taii...@gmx.com wrote:
> Of course, as I stated you have to bootstrap the crypto from the 
> motherboard EEPROM chip.
> >> One way is to use a blob-free coreboot IOMMU supporting board and
> >> bootstrap the crypto/kernel off of the board firmware EEPROM chip to
> >> load the initial kernel thus no plaintext touches the disk and thus
> >> nothing can mess with it.
> >>
> >> The IOMMU (theoretically) protects the CPU and memory from rogue
> >> devices, such as the hard drive.
> > No. Any DMA capable device can bypass IOMMU. IOMMU was not
> > designed to protect OS from device.
> That isn't true, it was designed for exactly that and of course for 
> assigning devices to VM's.
> 
> I get an AMD-Vi IOMMU IO_PAGE_FAULT alert in dmesg whenever a device 
> tries to do something it shouldn't and the remapping hardware blocks it.
> 
> In linux the kernel/drivers configure which memory locations the devices 
> are allowed to access.

This can be easily bypassed. See my reply to Rich in this thread.
It may protect you from accidental errors, it will not protect you
from malicious action.

> >> In terms of ethics IBM *for now* is a way better company than Intel/AMD,
> >> their POWER servers are owner controlled as there isn't any boot
> >> guard/secure boot/management engine/platform "security" processor (amd's
> >> ME) to stop you from re-writing the firmware as you please. They also
> >> have an getting-there-almost-reasonable open source effort (OpenPOWER)
> > Indeed they are. But that boxes are quite expensive and hard to get.
> Hard to get? You can buy them from IBM's website like any other computer.
> http://www-03.ibm.com/systems/power/hardware/linux-lc.html

There is no way to import them into my country now. In a year or
two maybe, but not now :/

Best regards,
Andrew Savchenko


pgpncblckJVCz.pgp
Description: PGP signature

Re: [gentoo-user] SHA-1 has just been broken

[Andrew Savchenko]

On Thu, 2 Mar 2017 19:04:06 -0500 Rich Freeman wrote:
> On Thu, Mar 2, 2017 at 6:26 PM, Andrew Savchenko  wrote:
> > On Thu, 2 Mar 2017 03:42:24 -0500 taii...@gmx.com wrote:
> >>
> >> The IOMMU (theoretically) protects the CPU and memory from rogue
> >> devices, such as the hard drive.
> >
> > No. Any DMA capable device can bypass IOMMU. IOMMU was not
> > designed to protect OS from device.
> >
> 
> Huh?  I thought protection against DMA attacks was half the reason for
> an IOMMU in the first place.
> 
> https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit
 
Even the page you cited contains:
``Some units also provide memory protection from faulty or
malicious devices.''

Please note the word "some" here.

IOMMU was created to restrict OS access to devices (and bring
desired guest VM direct hw access when needed). While it may be
used the other way around — to protect OS from device — it usually
don't work this way, not every IOMMU even supports this.

If we'll look further, IOMMU bypass is a part of normal operation
of many device drivers:
https://lists.gt.net/linux/kernel/365102

Just some real world examples, one can search the web or grep kernel
sources for more:
https://lwn.net/Articles/144207/
https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-February/115239.html

And the funniest stuff: even if IOMMU can be and is configured to
sandbox malicious devices, it can be easily bypassed in most real
world implementations:
https://hal.archives-ouvertes.fr/hal-01419962/document

So relying on IOMMU to protect from malicious devices is even more
naive than relying on SHA1 for crypto integrity needs.

Best regards,
Andrew Savchenko


pgpuiLIUE2qve.pgp
Description: PGP signature

Re: [gentoo-user] Re: CIFS mounts started misbehaving

[J. Roeleveld]

On March 6, 2017 8:17:37 PM GMT+01:00, Grant Edwards 
 wrote:
>On 2017-03-06, J. Roeleveld  wrote:
>> On March 6, 2017 5:14:39 PM GMT+01:00, Grant Edwards
> wrote:
>>>On 2017-03-06, Kai Krakow  wrote:
>>>
> I'm going to try to set up a Wireshark capture in ring-buffer mode
>>>and
> somehow detect the failure and stop the capture...

 Did something on the Windows side change?
>>>
>>>Probaby, but I've learned not to ask questions like that.  They never
>>>get answered, and it just causes problems when it is revealed that
>the
>>>client having problems is a Linux machine.
>>>
 Maybe force Windows down to a lower SMB version or reduce/disable
 SMB client side caching?
>>
>> Windows sharing is designed as a 'link when used' option. Not as a
>> permanent mount like Linix treats it.
>>
>> Even 'mounting' in Windows doesn't mean the share is actually
>> accessed.
>>
>> A windows CIFS server will not be reliable enough for long term
>> mounting. With Samba, it does work more reliable. (In my experience)
>
>It's worked perfectly fine for 10+ years, and apparently continues to
>do so for other Linux users in the office.

And trying to troubleshoot it is not simple. Especially as MS Windows event 
viewer never shows anything remotely useful. (I tried to troubleshoot various 
issues, never got anything usefull from the windows admins or event viewer)
How do the other Linux users access the shares?

>> For this reason, I use KDE/Dolphin to access CIFS shares. It is
>> closer to how Windows expects the shares to be treated.
>
>I don't see how things like shell scripts or other applications that
>need to access files on the CIFS mounts would use something like that.

Did you test if a small script that touches a file on the share every minute 
resolves the issue?

--
Joost


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[gentoo-user] Helvetica fonts

[thelma]

Which package contain "Helvetica" font?

I'm using "flpsed" and apparently it is using Helvetica font, which
"eselect fontconfig list" is not showing anything that resemble "helvet"
"eix helvet" is not showing anything either.

The fonts in "flpsed" display are very rugged/pixelated, it is hard to
look at them.

-- 
Thelma

[gentoo-user] Re: CIFS mounts started misbehaving

[Grant Edwards]

On 2017-03-06, J. Roeleveld  wrote:
> On March 6, 2017 5:14:39 PM GMT+01:00, Grant Edwards 
>  wrote:
>>On 2017-03-06, Kai Krakow  wrote:
>>
 I'm going to try to set up a Wireshark capture in ring-buffer mode
>>and
 somehow detect the failure and stop the capture...
>>>
>>> Did something on the Windows side change?
>>
>>Probaby, but I've learned not to ask questions like that.  They never
>>get answered, and it just causes problems when it is revealed that the
>>client having problems is a Linux machine.
>>
>>> Maybe force Windows down to a lower SMB version or reduce/disable
>>> SMB client side caching?
>
> Windows sharing is designed as a 'link when used' option. Not as a
> permanent mount like Linix treats it.
>
> Even 'mounting' in Windows doesn't mean the share is actually
> accessed.
>
> A windows CIFS server will not be reliable enough for long term
> mounting. With Samba, it does work more reliable. (In my experience)

It's worked perfectly fine for 10+ years, and apparently continues to
do so for other Linux users in the office.

> For this reason, I use KDE/Dolphin to access CIFS shares. It is
> closer to how Windows expects the shares to be treated.

I don't see how things like shell scripts or other applications that
need to access files on the CIFS mounts would use something like that.

-- 
Grant Edwards   grant.b.edwardsYow! I think my career
  at   is ruined!
  gmail.com

Re: [gentoo-user] Re: CIFS mounts started misbehaving

[J. Roeleveld]

On March 6, 2017 5:14:39 PM GMT+01:00, Grant Edwards 
 wrote:
>On 2017-03-06, Kai Krakow  wrote:
>
>>> I'm going to try to set up a Wireshark capture in ring-buffer mode
>and
>>> somehow detect the failure and stop the capture...
>>
>> Did something on the Windows side change?
>
>Probaby, but I've learned not to ask questions like that.  They never
>get answered, and it just causes problems when it is revealed that the
>client having problems is a Linux machine.
>
>> Maybe force Windows down to a lower SMB version or reduce/disable
>> SMB client side caching?

Windows sharing is designed as a 'link when used' option. Not as a permanent 
mount like Linix treats it.

Even 'mounting' in Windows doesn't mean the share is actually accessed.

A windows CIFS server will not be reliable enough for long term mounting. With 
Samba, it does work more reliable. (In my experience)

For this reason, I use KDE/Dolphin to access CIFS shares. It is closer to how 
Windows expects the shares to be treated.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[gentoo-user] Re: CIFS mounts started misbehaving

[Grant Edwards]

On 2017-03-06, Kai Krakow  wrote:

>> I'm going to try to set up a Wireshark capture in ring-buffer mode and
>> somehow detect the failure and stop the capture...
>
> Did something on the Windows side change?

Probaby, but I've learned not to ask questions like that.  They never
get answered, and it just causes problems when it is revealed that the
client having problems is a Linux machine.

> Maybe force Windows down to a lower SMB version or reduce/disable
> SMB client side caching?

-- 
Grant Edwards   grant.b.edwardsYow! Like I always say
  at   -- nothing can beat
  gmail.comthe BRATWURST here in
   DUSSELDORF!!

Re: [gentoo-user] Re: WARNING: Crucial MX300 drives SUUUUUCK!!!!

[Poison BL.]

On Mon, Mar 6, 2017 at 2:23 AM, Kai Krakow  wrote:

> Am Tue, 14 Feb 2017 16:14:23 -0500
> schrieb "Poison BL." :
> > I actually see both sides of it... as nice as it is to have a chance
> > to recover the information from between the last backup and the death
> > of the drive, the reduced chance of corrupt data from a silently
> > failing (spinning) disk making it into backups is a bit of a good
> > balancing point for me.
>
> I've seen bordbackup giving me good protection to this. First, it
> doesn't backup files which are already in the backup. So if data
> silently changed, it won't make it into the backup. Second, it does
> incremental backups. Even if something broke and made it into the
> backup, you can eventually go back weeks or months to get back the
> file. The algorithm is very efficient. And every incremental backup is
> a full backup at the same time - so you thin out backup history by
> deleting any backup at any time (so it's not like traditional
> incremental backup which always needs the parent backup).
>
> OTOH, this means that every data block is only stored once. If silent
> data corruption is hitting here, you loose the complete history of this
> file (and maybe others using the same deduplicated block).
>
> For the numbers, I'm storing my 1.7 TB system into a 3 TB disk which is
> 2.2 TB full now. But the backup history is almost 1 year now (daily
> backups).
>
> As a sort of protection against silent data corruption, you could rsync
> borgbackup to a remote location. The differences are usually small, so
> that should be a fast operation. Maybe to some cloud storage or RAID
> protected NAS which can detect and correct silent data corruption (like
> ZFS or btrfs based systems).
>
>
> --
> Regards,
> Kai
>
> Replies to list-only preferred.
>

That's some impressive backup density... and I haven't looked into
borgbackup, but it sounds like it runs on the same principles as the
rsync+hardlink based scripts I've seen, though those will back up files
that've silently changed, since the checksums won't match any more, but
that won't blow away previous copies of the file either. I'll have to give
it a try!

As for protecting against the backup set itself getting silent corruption,
an rsync to a remote location would help, but you would have to ensure it
doesn't overwrite anything already there that may've changed, only create
new. Also, making the initial clone would take ages, I suspect, since it
would have to rebuild the hardlink set for everything (again, assuming
that's the trick borgbackup's using). One of the best options is to house
the base backup set itself on something like zfs or btrfs on a system with
ecc ram, and maintain checksums of everything on the side (crc32 would
likely suffice, but sha1's fast enough these days there's almost no excuse
not to use it). It might be possible to task tripwire to keep tabs on that
side of it, now that I consider it. While the filesystem itself in that
case is trying its best to prevent issues, there's always that slim risk
that there's a bug in the filesystem code itself that eats something, hence
the added layer of paranoia. Also, with ZFS for the base data set, you gain
in-place compression, dedup if you're feeling adventurous (not really worth
it unless you have multiple very similar backup sets for different
systems), block level checksums, redundancy across physical disks, in place
snapshots, and the ability to use zfs send/receive to do snapshot backups
of the backup set itself.

I managed to corrupt some data with zfs (w/ dedup, on gentoo) shared out
over nfs a while back on a box with way too little ram a while back
(nothing important, throwaway VM images), hence the paranoia of secondary
checksum auditing and still replicating the backup set for things that
might be important.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] Re: No room left on /boot

[thelma]

On 03/06/2017 12:05 AM, Kai Krakow wrote:
> Am Sun, 5 Mar 2017 14:33:03 -0700
> schrieb the...@sys-concept.com:
> 
>> After upgrading my machine. I rebooted, everything went as planned.
>> So I decided to upgrade to a newer kernel.  I was using:
>> linux-3.10.7-gentoo-r1
>>
>> and decided to switch to:
>> linux-4.9.6-gentoo-r1
>>
>> I've done kernel upgrade many, many times so it was a routine
>> procedure. When I re-booted the last thing on the screen were letter:
>>
>> "GRUB" and blank screen, not even a kernel selection.
>> I scramble, boot strap the system and copied two file in /boot/ 
>> kernel-old --> kernel-current
>> System.map-old --> System.map-current
>>
>> I was under impression that something is wrong with the current
>> (newest kernel). But it seems to me I run out of room on the /boot
>> partition.
>>
>> ll -h /boot/
>> total 17M
>> lrwxrwxrwx 1 root root1 Dec 17  2011 boot -> .
>> -rw-r--r-- 1 root root 109K Mar  5 10:20 config-current
>> -rw-r--r-- 1 root root  90K Mar  5 10:13 config-old
>> drwxr-xr-x 5 root root 1.0K Mar  5 11:48 grub
>> -rw-r--r-- 1 root root 5.5M Mar  5 11:03 kernel-current
>> -rw-r--r-- 1 root root 5.5M Mar  5 10:12 kernel-old
>> drwx-- 2 root root  12K Dec 17  2011 lost+found
>> -rw-r--r-- 1 root root 2.9M Mar  5 11:03 System.map-current
>> -rw-r--r-- 1 root root 2.9M Mar  5 10:12 System.map-old
>>
>> df -h
>> /dev/sda130M   29M 0 100% /boot
> 
> Please have a look a lost+found and clear the contents. 12k size for a
> directory node that should be empty looks a bit too big to me.
> 
> But I recommend to bump that size of the partition up, really. 32M is
> so 1990s.

It is empty.  I can delete the dir. but it will not gain me much space.
I've move the *-old to a root dir not know and copied just new kernel to
/boot

ll -alh /boot/lost+found/
total 13K
drwx-- 2 root root  12K Dec 17  2011 .
drwxr-xr-x 4 root root 1.0K Mar  5 17:20 ..

--
Thelma

Re: [gentoo-user] Re: fonts mostly inaccessable to xterm

[Mick]

On Sunday 05 Mar 2017 19:52:18 Harry Putnam wrote:
> Corbin Bird  writes:
> > Have you tried : xterm -fa "9x15B-ISO8859-1"?
> 
> I mentioned that the -fa switch was not working at all.
> 
> I've since discovered that the xterms I had were compiled with useflag
> truetype disabled .. so `-truetype' Which meant xterm was compiled
> without support for -fa
> 
> > Note : that works on XTerm v325 ( tested ).
> 
> I've recompiled xterm with useflag truetype enabled and now I have the
> -fa flag so I can run the command you mentioned above now.
> 
> That is a nice looking font... a little big on my view but
> 
> I see something a bit off here... trying to get a smaller font of the
> same type I went clear down to 4x6... but those all look just like
> the "9x15B-ISO8859-1"
> 
>   xterm -fa 4x6-ISO8859-1
> 
> Does not say anything by way of error or explanation just shows a
> terminal with the same font displayed as "9x15B-ISO8859-1"
> 
> That can't be a desirable outcome.
> 
> It must just be displaying the same size from 9x 8x 7x 6x 5x 4x. and
> doing so silently.

Have you tried creating a ~/.Xresources file with something like:

xterm*faceSize:12
xterm*faceSize1:6
xterm*faceSize2:8
xterm*faceSize3:10
xterm*faceSize4:12
xterm*faceSize5:14
xterm*faceSize6:16

This seems to work here, but I do not change font sizes in real time.

-- 
Regards,
Mick

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

Re: [gentoo-user] 32 bit firefox on 64 bit system

[Jorge Almeida]

On Mon, Mar 6, 2017 at 1:55 AM, R0b0t1  wrote:
> On Sat, Mar 4, 2017 at 4:22 AM, Jorge Almeida  wrote:
>> Is it possible?
>>
>
> Yes, the most straightforward way I know of is to use crossdev to
> create an i[3456]86 GCC and compile it with the corresponding
> cross-emerge executable. It will then install to /usr/$ARCH and you
> should be able to copy it to your root.

I've compiled 32 bit stuff before, using a chroot environment from a
musl-based distro. But that would produce a static executable. For a
beast like ff and a glibc environment, I fear this would not work, or
at least it would be a time sink to make it work, which I cannot
afford.

I was hoping some USE variable et al. would do the job, given that I
already have multilib USE variable, but I suppose it's not that
simple.

I think I'll give chromium a try, although last time I tried it was a
CPU hog, specially with Youtube...
(Not to mention that I don't trust Google...)

>

>
> I'm inclined to disagree with your determination that switching to a
> 64bit OS caused the slowdown, but, at the same time, you're the one

Maybe, but I'm out of alternatives.

> who was there to notice the correlation. If your determination is
> correct it may be best to go back to a 32bit system - unlike ARM64
> processors, which seem to suffer spectacularly when operating in 32bit
> - early x86_64 processors may not have a penalty or be faster in the
> more restricted mode.

The reason I tried a 64 bit system was not speed-related: it is said
some software just doesn't work on 32 bit systems (e.g., widevine,
which I don't need, BTW), and I suppose that is a trend, so I thought
I might try 64 bit. Not a great choice, I guess.

>
> When this kind of question comes up I tend to bring up the opportunity
> to upgrade the computer as well. This tends to have many benefits in
> regards to power usage and overall system responsiveness, but I
> understand if it's not possible. I would point out that technology is
> usually amortized over a 3 year period and conventional wisdom
> dictates if you keep a computer longer than that as a business you are
> losing money due to opportunity cost of using and maintaining older
> and slower hardware.

This is a home computer. I do have another one, but this is the silent
one (no internal power supply unit). I don't know of similar
alternatives (silent for music listening, low power consumption, but
powerful enough for everyday computing-- I don't use for compiling the
gentoo packages)

Thanks

Jorge