Re: stretch update overwrites nano file

[Pascal Hambourg]

Le 27/11/2018 à 20:15, Brian a écrit :

On Tue 27 Nov 2018 at 11:07:33 +, Bonno Bloksma wrote:


Yup, I simply put my default.nanorc file back into the /usr/share/nano
dir. I want it to be a system wide default as the current default is
"a bit sparse" ;-)


Then you used dpkg-divert to be able to sleep better at nights and not
have to worry about it being overwritten?


This is a good advice for the future, but default.nanorc did not exist 
in Jessie's nano package, so there was nothing to divert before the 
upgrade. The OP was unlucky to choose a file name which will was used in 
the next version.



It would not have been better to have been given a warning. Any admin
who alters a system file should know what he is doing and be able to
deal with it.


The OP did dot alter a system file, the file did not exist in Jessie's 
package.

Re: stretch update overwrites nano file

[Richard Hector]

On 28/11/18 12:07 AM, Bonno Bloksma wrote:

> Tixy quoted from nanorc(5):
>
>>   During startup, nano will first read the system-wide settings, from
>>  /etc/nanorc (the exact path might be different), and then the user-
>>  specific settings, from ~/.nanorc.
>> So, the correct file to customise nano settings is either of those two files.
> 
> Yup, I simply put my default.nanorc file back into the /usr/share/nano dir. I 
> want it to be a system wide default as the current default is "a bit sparse" 
> ;-)

Why not put it at /etc/nanorc? The Debian package ships it (it's there
on my system), and expects it to be edited (it's entirely full of
comments). That's what it's there for.

/usr/share/nano appears to be for basic defaults that can be overridden
either at the system or the user level.

Richard



signature.asc
Description: OpenPGP digital signature

Re: libcurl problem.

[Gene Heskett]

On Tuesday 27 November 2018 21:20:16 Roberto C. Sánchez wrote:

> On Tue, Nov 27, 2018 at 03:51:47PM -0500, Gene Heskett wrote:
> > curl (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1
> > libcurl3 (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1
> > libcurl3-gnutls (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1
> > libcurl4-gnutls-dev (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1
> >
> > I knew I'd been looking at the error, but I didn't think it was THAT
> > far back up the log.  But an app I hadn't used in a coupler years,
> > refused to go get the docs for a new version, which made me back it
> > up to the previous version I was familiar with, also refused, I
> > thought I'd dig a little deeper.
> >
> > Abd the fix is?
>
> Can you try to launch the offending application from the terminal and
> post the complete error output?
>
> Regards,
>
Ton't take long, its name is DriveWire, writtem in java. It sets up a 
very high baud rate serial connection to an old TRS-80 Color Computer3 
over a usb2 to a 7 port usb hub in the basement, which has a custom 
built adapter cable plugged into the coco's bit banger port, giving 
the coco 32 additional channels of i/o that can be used as virtual 
disk drives, virtual terminal screens into the coco from a pc's screen.
a midi player, and access in text modes, to any printer attached to 
the pc.  All at speeds of about half that of a floppy controller.

I fired it up, and sent it to show me the documentation from the 
drivewire wiki pages.  And this is the trace:

==
ene@coyote:/CoCo$ ./dwstart
/CoCo/dw4directory
gene@coyote:/CoCo$ deleting old lockfile /var/lock/LCK..ttyUSB1
total 0
drwxr-xr-x 2 www-data root 40 Nov 19 20:20 apache2
-rw-rw-rw- 1 root root  0 Nov 19 20:20 tdekbdledsync-:0.lock
total 0
drwxr-xr-x 2 www-data root 40 Nov 19 20:20 apache2
-rw-rw-rw- 1 root root  0 Nov 19 20:20 tdekbdledsync-:0.lock
27 Nov 2018 22:00:34 INFO  [dwserver-9] DriveWire Server v4.3.3o starting
Warning: NineServer port already in use.  Is another DW4UI running?
/usr/bin/x-www-browser: error while loading shared libraries: libcurl.so.4: 
cannot open shared object file: No such file or 
directory
===
At that point I exited the app. The NineServer port message has been 
there for years, thru at least a dozen new versions and has never 
been a problem. At that point it had not yet drawn its gui, taking 
another 3 or 4 secs to complete that.  At that point I opened the help
pulldown and ask to see the docs from te wiki.

And thats is the complete trace, showing the libcurl.so.4 as not being loadable.

But its there:
 ls -l /usr/lib/i386-linux-gnu/libcurl*
lrwxrwxrwx 1 root root 16 May 16  2018 /usr/lib/i386-linux-gnu/libcurl.a -> 
libcurl-gnutls.a
-rw-r--r-- 1 root root 596234 May 16  2018 
/usr/lib/i386-linux-gnu/libcurl-gnutls.a
-rw-r--r-- 1 root root990 May 16  2018 
/usr/lib/i386-linux-gnu/libcurl-gnutls.la
lrwxrwxrwx 1 root root 23 May 16  2018 
/usr/lib/i386-linux-gnu/libcurl-gnutls.so -> libcurl-gnutls.so.4.2.0
lrwxrwxrwx 1 root root 19 May 16  2018 
/usr/lib/i386-linux-gnu/libcurl-gnutls.so.3 -> libcurl-gnutls.so.4
lrwxrwxrwx 1 root root 23 May 16  2018 
/usr/lib/i386-linux-gnu/libcurl-gnutls.so.4 -> libcurl-gnutls.so.4.2.0
-rw-r--r-- 1 root root 412384 May 16  2018 
/usr/lib/i386-linux-gnu/libcurl-gnutls.so.4.2.0
lrwxrwxrwx 1 root root 17 May 16  2018 /usr/lib/i386-linux-gnu/libcurl.la 
-> libcurl-gnutls.la
lrwxrwxrwx 1 root root 17 May 16  2018 /usr/lib/i386-linux-gnu/libcurl.so 
-> libcurl-gnutls.so
lrwxrwxrwx 1 root root 12 May 16  2018 /usr/lib/i386-linux-gnu/libcurl.so.3 
-> libcurl.so.4
lrwxrwxrwx 1 root root 16 May 16  2018 /usr/lib/i386-linux-gnu/libcurl.so.4 
-> libcurl.so.4.2.0
-rw-r--r-- 1 root root 433152 May 16  2018 
/usr/lib/i386-linux-gnu/libcurl.so.4.2.0

Me not java expert except for drinking it. :-)

Doing a new ldconfig makes no difference.

Thanks Roberto C. Sánchez.

> -Roberto

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: libcurl problem.

[Roberto C . Sánchez]

On Tue, Nov 27, 2018 at 03:51:47PM -0500, Gene Heskett wrote:
> 
> curl (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1
> libcurl3 (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1
> libcurl3-gnutls (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1
> libcurl4-gnutls-dev (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1
> 
> I knew I'd been looking at the error, but I didn't think it was THAT far 
> back up the log.  But an app I hadn't used in a coupler years, refused 
> to go get the docs for a new version, which made me back it up to the 
> previous version I was familiar with, also refused, I thought I'd dig a 
> little deeper.
> 
> Abd the fix is? 
> 
Can you try to launch the offending application from the terminal and
post the complete error output?

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: libcurl problem.

[Gene Heskett]

On Tuesday 27 November 2018 17:20:29 Brian wrote:

> On Tue 27 Nov 2018 at 16:26:19 -0500, Gene Heskett wrote:
> > On Tuesday 27 November 2018 15:55:18 Brian wrote:
> > > On Tue 27 Nov 2018 at 15:51:47 -0500, Gene Heskett wrote:
> > > > On Tuesday 27 November 2018 15:11:55 Roberto C. Sánchez wrote:
> > > > > Did you just recently update curl?
> > > >
> > > > About the first of october, it came from security.debian.org
> > > > IIRC, but
> > >
> > > You do not recall IIRC.
> >
> > Obviously but I'm rubbing it in bad enough w/o help ;)
>
> Knowing which package was installed would be useful. It should be in
> you logs.

I already posted that list. Up-thread.



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: VLC doesn't shutdown when closed

[Gary Dale]

On 2018-11-27 12:58 p.m., Gary Dale wrote:

On 2018-11-27 3:22 a.m., Curt wrote:

On 2018-11-27, Gary Dale  wrote:


If you read the other discussion, the problem seems to be related with
what controls you have added to the interface. If you just use the 
stock

interface, it works. Adding speed controls creates the issue.


I added the 'faster' and 'slower' speed controls to the time toolbar in
vlc, started a video, stopped it by clicking the upper right-hand X of
the video's graphical window, but failed to reproduce the symptoms
you've described.


The VLC maintainers appear to have finally fixed the problem.


I spoke too soon. I'm still having it.

Buster: Kvirc: Bug 908420: Am I the only one who's having this issue?

[local10]

Hi,

Am I the only one who's having this issue? It's kind of annoying and there's no 
response from the maintenance team:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908420 


Regards,

Re: libcurl problem.

[Brian]

On Tue 27 Nov 2018 at 16:26:19 -0500, Gene Heskett wrote:

> On Tuesday 27 November 2018 15:55:18 Brian wrote:
> 
> > On Tue 27 Nov 2018 at 15:51:47 -0500, Gene Heskett wrote:
> > > On Tuesday 27 November 2018 15:11:55 Roberto C. Sánchez wrote:
> > > > Did you just recently update curl?
> > >
> > > About the first of october, it came from security.debian.org IIRC,
> > > but
> >
> > You do not recall IIRC.
> 
> Obviously but I'm rubbing it in bad enough w/o help ;)

Knowing which package was installed would be useful. It should be in
you logs.

-- 
Brian.

Re: libcurl problem.

[Gene Heskett]

On Tuesday 27 November 2018 15:55:18 Brian wrote:

> On Tue 27 Nov 2018 at 15:51:47 -0500, Gene Heskett wrote:
> > On Tuesday 27 November 2018 15:11:55 Roberto C. Sánchez wrote:
> > > Did you just recently update curl?
> >
> > About the first of october, it came from security.debian.org IIRC,
> > but
>
> You do not recall IIRC.

Obviously but I'm rubbing it in bad enough w/o help ;)


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: libcurl problem.

[Brian]

On Tue 27 Nov 2018 at 15:51:47 -0500, Gene Heskett wrote:

> On Tuesday 27 November 2018 15:11:55 Roberto C. Sánchez wrote:
> 
> > Did you just recently update curl?
> >
> About the first of october, it came from security.debian.org IIRC, but 

You do not recall IIRC.

-- 
Brian.

Re: Still unable to restart networking on Debian 9 text mode only

[David Wright]

On Mon 26 Nov 2018 at 18:32:47 (-0500), Gary Dale wrote:
> On 2018-11-26 7:57 a.m., Luciano Andress Martini wrote:
> > Good morning Rob,
> > Your message is what i am expecting to receive...
> > 
> > Please don't judge me if you are a dedicated developer of Debian. I
> > love and I am using it since the first versions, but I never come to
> > this list because I am not welcome in groups in my life, and will be
> > no different here. And i promisse I you get out from here the faster
> > as I can, I just can't believe what you are doing to Debian...
> > 
> > In older Debian versions, I am able to just do this:
> > #vi /etc/network/interfaces
> > #at 20:00
> > > ifdown eth0
> > > sleep 10
> > > ifup eth0
> > CTRL+D
> > 
> > Debian must have a option during the installation a option like
> > "Legacy mode"  that install sysvinit, net-tools, and etc this will
> > make everyone here happy.

I don't see the connection between this and the OP problem.

> sysvinit is going the way of the dodo. I have nothing against it
> personally but some things deserve a dignified retirement. Being able
> to configure things with a few declarative files and standard commands
> is simply a better way to run an operating system.
> 
> Your example suggests that you want to change the ip address "after
> hours". You can still do the same thing pretty much the same way. If
> you are using the interfaces file, I don't see why your example won't
> work as is.

That's already dealt with in the thread.

> In my case, I can simply change the ip address in
> /etc/systemd/network/Management.network then instead of all the
> commands you want to run, just do systemctl restart systemd-networkd.
> Again, you can put that into an ad hoc script to run with "at" if you
> want.

That would seem to be most unhelpful to someone who, if they're
running systemd at all, appears to be doing so reluctantly.

Cheers,
David.

Re: Worked example, was Re: Still unable to restart networking on Debian 9 text mode only

[David Wright]

On Mon 26 Nov 2018 at 18:17:08 (-0500), Gary Dale wrote:
> On 2018-11-25 10:14 a.m., David Wright wrote:
> > On Sat 24 Nov 2018 at 21:33:18 (-0500), Gary Dale wrote:
> > > On 2018-11-24 9:05 p.m., David Wright wrote:
> > > > So you can see the extra work (worth more than two cents) that
> > > > the higher level commands do for you automatically, thanks to
> > > > /etc/network/if-*.d/*
> > > That, of course, assumes that ifup and ifdown work on your system.
> > > They don't work on two of my systems that uses systemd-networkd to
> > > control the network.
> > I don't understand why you would *want* to use ifup/ifdown on a system
> > where you've chosen to control the interface with systemd-networkd.
> > The only reason I bothered to actually perform the worked example was
> > because I have one host that's still using what the installer left
> > as its default.
> 
> I don't

Then don't. I don't know why you wrote "That, of course, assumes that
ifup and ifdown work on your system." If you've set up your system to
use ifupdown they'll work. If you haven't, they might not. Pretty obvious.


> but the OP seems to and your assistance used it. You defended
> the use of "high level tools" even when they make things more
> complicated.

They don't. The OP just couldn't put the commands in the right order.

> > > However ifconfig works on one and ip works on the
> > > other (although they are both running Stretch, one is a new
> > > server-type install while the other has been upgraded over the years
> > > from earlier versions).
> > Perhaps it would be useful to discover why, and then post any helpful
> > hints on what to do or avoid if other shave such a problem.
> 
> It's not a problem. It's how the two systems developed. Ifconfig no
> longer is installed by default on Debian systems. Ip is used instead.

You seem to use "work" unidiomatically. When someone says they have
two objects A and B, and that tool T works with A and tool U works
with B, that usually means there's some problem with U and A and/or
with T and B. Otherwise, they would say that they *use* T with A and
U with B.

It's still odd, to me, that you don't either install ifconfig on the
non-upgraded system or use ip on both, but there we are.

> > > The lower-level tools tend to be more flexible and are more agnostic
> > > regarding how your network is set up.
> > Yes, one might suppose that the high-level tools use the low-level ones
> > in a pre-arranged (hence less flexible) manner to do the actual work.
> > 
> > > In the case of the OP, he needs to change his interfaces file no
> > > matter how he changes the network. However the order of commands isn't
> > > important when he uses ifconfig or ip to update the ip address - he
> > > can do it before or after editing interfaces. Moreover, it takes one
> > > fewer command. And it's worth learning how to use these tools if you
> > > are working with networks.
> > I don't understand why you'd recommend using a particular method when
> > you've just explained that you can't get it to run consistently on
> > your own systems. Nor do I understand why the number of commands
> > required is of such importance: isn't that what scripts are for.
> > One reply suggested installing network manager just to reduce the
> > command count to two. That's a 15 package installation on my system.
> 
> Again, its a matter of using what you have. If you have ifconfig, it's
> straightforward to change the ip address of a running network. Ip is
> only slightly more complicated and should be used since ifconfig seems
> to be losing favour.
> 
> Ip works on systems that don't use /etc/network/interfaces, such as
> ones that use systemd-networkd to control their network, while
> ifup/down only work with the interfaces file. Learn how to use it and
> your knowledge will be worth something for a longer time.
> 
> You don't need network manager to reduce the command count. Just use
> the tools you already have.

That's just what the OP was trying to do.

Cheers,
David.

Re: libcurl problem.

[Gene Heskett]

On Tuesday 27 November 2018 15:11:55 Roberto C. Sánchez wrote:

> On Tue, Nov 27, 2018 at 02:58:17PM -0500, Gene Heskett wrote:
> > On Tuesday 27 November 2018 14:40:40 Roberto C. Sánchez wrote:
> > > apt-cache policy $(dpkg -l |grep libcurl | awk '{print $2}')
> >
> > gene@coyote:/CoCo$ sudo apt-cache policy $(dpkg -l |grep libcurl |
> > awk '{print $2}')
> > [sudo] password for gene:
> > libcurl3:
> >   Installed: 7.26.0-1+wheezy25+deb7u1
> >   Candidate: 7.26.0-1+wheezy25+deb7u1
> >   Version table:
> >  *** 7.26.0-1+wheezy25+deb7u1 0
> > 100 /var/lib/dpkg/status
> >  7.26.0-1+wheezy13 0
> > 500 http://deb.debian.org/debian/ wheezy/main i386 Packages
> > libcurl3-gnutls:
> >   Installed: 7.26.0-1+wheezy25+deb7u1
> >   Candidate: 7.26.0-1+wheezy25+deb7u1
> >   Version table:
> >  *** 7.26.0-1+wheezy25+deb7u1 0
> > 100 /var/lib/dpkg/status
> >  7.26.0-1+wheezy13 0
> > 500 http://deb.debian.org/debian/ wheezy/main i386 Packages
> > libcurl4-gnutls-dev:
> >   Installed: 7.26.0-1+wheezy25+deb7u1
> >   Candidate: 7.26.0-1+wheezy25+deb7u1
> >   Version table:
> >  *** 7.26.0-1+wheezy25+deb7u1 0
> > 100 /var/lib/dpkg/status
> >  7.26.0-1+wheezy13 0
> > 500 http://deb.debian.org/debian/ wheezy/main i386 Packages
> > python-pycurl:
> >   Installed: 7.19.0-5
> >   Candidate: 7.19.0-5
> >   Version table:
> >  *** 7.19.0-5 0
> > 500 http://deb.debian.org/debian/ wheezy/main i386 Packages
> > 100 /var/lib/dpkg/status
> >
> > Is this helpfull?
> >
> > Rhanks Roberto C. Sánchez
>
> The version you have installed first appeared 6 months ago:
>
> http://snapshot.debian.org/package/curl/7.26.0-1%2Bwheezy25%2Bdeb7u1/
>
> Here is the related Debian LTS Advisory:
>
> https://lists.debian.org/debian-lts-announce/2018/05/msg00010.html
>
> Did you just recently update curl?
>
About the first of october, it came from security.debian.org IIRC, but 
let me see if I can find it in Synaptics history to be exact & sure of 
the date . Damn, clear back in May 17 2018, I see this:

curl (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1
libcurl3 (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1
libcurl3-gnutls (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1
libcurl4-gnutls-dev (7.26.0-1+wheezy25) to 7.26.0-1+wheezy25+deb7u1

I knew I'd been looking at the error, but I didn't think it was THAT far 
back up the log.  But an app I hadn't used in a coupler years, refused 
to go get the docs for a new version, which made me back it up to the 
previous version I was familiar with, also refused, I thought I'd dig a 
little deeper.

Abd the fix is? 

> Regards,
>
> -Roberto

Thanks Roberto C. Sánchez

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: libcurl problem.

[Roberto C . Sánchez]

On Tue, Nov 27, 2018 at 02:58:17PM -0500, Gene Heskett wrote:
> On Tuesday 27 November 2018 14:40:40 Roberto C. Sánchez wrote:
> 
> > apt-cache policy $(dpkg -l |grep libcurl | awk '{print $2}')
> 
> gene@coyote:/CoCo$ sudo apt-cache policy $(dpkg -l |grep libcurl | 
> awk '{print $2}')
> [sudo] password for gene:
> libcurl3:
>   Installed: 7.26.0-1+wheezy25+deb7u1
>   Candidate: 7.26.0-1+wheezy25+deb7u1
>   Version table:
>  *** 7.26.0-1+wheezy25+deb7u1 0
> 100 /var/lib/dpkg/status
>  7.26.0-1+wheezy13 0
> 500 http://deb.debian.org/debian/ wheezy/main i386 Packages
> libcurl3-gnutls:
>   Installed: 7.26.0-1+wheezy25+deb7u1
>   Candidate: 7.26.0-1+wheezy25+deb7u1
>   Version table:
>  *** 7.26.0-1+wheezy25+deb7u1 0
> 100 /var/lib/dpkg/status
>  7.26.0-1+wheezy13 0
> 500 http://deb.debian.org/debian/ wheezy/main i386 Packages
> libcurl4-gnutls-dev:
>   Installed: 7.26.0-1+wheezy25+deb7u1
>   Candidate: 7.26.0-1+wheezy25+deb7u1
>   Version table:
>  *** 7.26.0-1+wheezy25+deb7u1 0
> 100 /var/lib/dpkg/status
>  7.26.0-1+wheezy13 0
> 500 http://deb.debian.org/debian/ wheezy/main i386 Packages
> python-pycurl:
>   Installed: 7.19.0-5
>   Candidate: 7.19.0-5
>   Version table:
>  *** 7.19.0-5 0
> 500 http://deb.debian.org/debian/ wheezy/main i386 Packages
> 100 /var/lib/dpkg/status
> 
> Is this helpfull?
> 
> Rhanks Roberto C. Sánchez
> 
The version you have installed first appeared 6 months ago:

http://snapshot.debian.org/package/curl/7.26.0-1%2Bwheezy25%2Bdeb7u1/

Here is the related Debian LTS Advisory:

https://lists.debian.org/debian-lts-announce/2018/05/msg00010.html

Did you just recently update curl?

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: libcurl problem.

[Brian]

On Tue 27 Nov 2018 at 14:25:55 -0500, Gene Heskett wrote:

> Greetings all;
> 
> One of the last updates to wheezy was libcurl, from security.debian.org,

No, it wasn't from security.debian.org.

> to libcurl.so.4.2.0 which was installed by symlinking it to 
> libcurl.so.4, which is what the erroir.
> 
> Normally when you folks do that, the symlink says it is 100% compatible 
> with the older version.
> 
> But everything on my system that needs libcurl.so.4 is yelling about it 
> can't be found.
> 
> How to fix this if possible?

Look at what you had before and what you have now.

-- 
Brian.

Re: libcurl problem.

[Gene Heskett]

On Tuesday 27 November 2018 14:40:40 Roberto C. Sánchez wrote:

> apt-cache policy $(dpkg -l |grep libcurl | awk '{print $2}')

gene@coyote:/CoCo$ sudo apt-cache policy $(dpkg -l |grep libcurl | 
awk '{print $2}')
[sudo] password for gene:
libcurl3:
  Installed: 7.26.0-1+wheezy25+deb7u1
  Candidate: 7.26.0-1+wheezy25+deb7u1
  Version table:
 *** 7.26.0-1+wheezy25+deb7u1 0
100 /var/lib/dpkg/status
 7.26.0-1+wheezy13 0
500 http://deb.debian.org/debian/ wheezy/main i386 Packages
libcurl3-gnutls:
  Installed: 7.26.0-1+wheezy25+deb7u1
  Candidate: 7.26.0-1+wheezy25+deb7u1
  Version table:
 *** 7.26.0-1+wheezy25+deb7u1 0
100 /var/lib/dpkg/status
 7.26.0-1+wheezy13 0
500 http://deb.debian.org/debian/ wheezy/main i386 Packages
libcurl4-gnutls-dev:
  Installed: 7.26.0-1+wheezy25+deb7u1
  Candidate: 7.26.0-1+wheezy25+deb7u1
  Version table:
 *** 7.26.0-1+wheezy25+deb7u1 0
100 /var/lib/dpkg/status
 7.26.0-1+wheezy13 0
500 http://deb.debian.org/debian/ wheezy/main i386 Packages
python-pycurl:
  Installed: 7.19.0-5
  Candidate: 7.19.0-5
  Version table:
 *** 7.19.0-5 0
500 http://deb.debian.org/debian/ wheezy/main i386 Packages
100 /var/lib/dpkg/status

Is this helpfull?

Rhanks Roberto C. Sánchez

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: libcurl problem.

[Roberto C . Sánchez]

On Tue, Nov 27, 2018 at 02:25:55PM -0500, Gene Heskett wrote:
> Greetings all;
> 
> One of the last updates to wheezy was libcurl, from security.debian.org, 
> to libcurl.so.4.2.0 which was installed by symlinking it to 
> libcurl.so.4, which is what the erroir.
> 
> Normally when you folks do that, the symlink says it is 100% compatible 
> with the older version.
> 
> But everything on my system that needs libcurl.so.4 is yelling about it 
> can't be found.
> 
> How to fix this if possible?
> 
What is the output of this command:

apt-cache policy $(dpkg -l |grep libcurl | awk '{print $2}')


-- 
Roberto C. Sánchez

Re: Looking for a "friendly" e-mail service

[Gene Heskett]

On Tuesday 27 November 2018 09:49:22 John Hasler wrote:

[...]

> You've reinvented parts of Mailagent and Exim.

With something I am familiar with and doesn't need a 200 page help file. 
Similar to skinning cats, first make sure its truly dead. ;-)

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: stretch update overwrites nano file

[Brian]

On Tue 27 Nov 2018 at 11:07:33 +, Bonno Bloksma wrote:

[Snip]

> >   During startup, nano will first read the system-wide settings, from
> >  /etc/nanorc (the exact path might be different), and then the user-
> >  specific settings, from ~/.nanorc.
> > So, the correct file to customise nano settings is either of those two 
> > files.
> 
> Yup, I simply put my default.nanorc file back into the /usr/share/nano
> dir. I want it to be a system wide default as the current default is
> "a bit sparse" ;-)

Then you used dpkg-divert to be able to sleep better at nights and not
have to worry about it being overwritten?

> I now better understand the logic why my default file got replaced.
> Still it would have been better if there was some kind of warning but
> I understand the logic and I can live with it. :-)

It would not have been better to have been given a warning. Any admin
who alters a system file should know what he is doing and be able to
deal with it. Think of a hundred altered files and a hundred warnings
during an upgrade.

Another point is that /usr/local is the place for non-package files.

-- 
Brian.

libcurl problem.

[Gene Heskett]

Greetings all;

One of the last updates to wheezy was libcurl, from security.debian.org, 
to libcurl.so.4.2.0 which was installed by symlinking it to 
libcurl.so.4, which is what the erroir.

Normally when you folks do that, the symlink says it is 100% compatible 
with the older version.

But everything on my system that needs libcurl.so.4 is yelling about it 
can't be found.

How to fix this if possible?

Thank you all.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: issues with stretch, part 1 of many

[Étienne Mollier]

On 11/27/18 2:05 PM, Ionel Mugurel Ciobîcă wrote:
> On 27-11-2018, at 13h 33'55", Ionel Mugurel Ciobîcă wrote about "issues with 
> stretch, part 1 of many"
>>
>>
>> Dear all,
>>
[...]
>>
>> The first question I want to ask relates to ssh, ssh-ask and
>> ssh-agent. When I ssh to another computer I am asked "Allow use of key
>> id_rsa? Key fingerprint ..." If I uninstall all ssh-ask programs I
>> simply can't use the ssh-agent anymore and I am prompted for password.
>> I try ssh-ask, ssh-ask-fullscreen, ssh-ask-gnome and the similar from
>> kde. I check the /etc/ssh/ssh_config and /etc/ssh/sshd_config for
>> anything that may relate to this. The only think coming close are:
>> UsePAM yes
>> ChallengeResponseAuthentication no
>>
>> Is there something I overlook?
>>
>> To be clear, I do not want to be asked if I allow the use of a key, I
>> just want this to be assumed yes, as it was the case in the past.
>>
>> So, I run Linux 4.9.0-8-amd64, Debian 9u6. ssh is openssh_7.4p1,
>> openssl 1.0.2l ssh-agent is started in $HOME/.xsessionrc as:
>> eval `ssh-agent -s`
>>

Good Day Ionel,

According to my experience, when ssh-agent is started, it is
ready store passphrase and decipher the private key.  However,
it doesn't do this automatically when I type my passphrase at
a connection attempt.

Before issuing any SSH connection, I run ssh-add and type my
passphrase.  Afterwards, I can connect to any machine accepting
my key.  I'm not exactly sure this is the right way to do it in
terms of security, but it does the job in terms of convenience.
:^)

Concerning ssh-ask programs, they are merely useful in
situations where the SSH client has no access to the terminal.

> A hint of the followup questions already is given by the ssh-agent the
> first time when the passphrase is introduced, by announcing: "Enter
> passphrase for id_rsa (will confirm each use):".
>
> I do not want to confirm each usage. My .xsession(rc) contains many
> calls of "xterm -e ssh ..." using -geometry to position the xterms,
> and all of those "allow use of key..." questions agglomerates on the
> same place, one on top of each other. I do not understand conceptually
> why this would be desired (to be asked again and again). The point of
> ssh-agent was to make it simpler, not more complicated. If I want to
> be asked, I will not use the agent, so I can input password when
> connecting...

You should probably run your connections in a side script
instead of your session startup script.  This way, you have a
chance to run ssh-add before issuing connections, but after
starting the SSH agent.

Have a look at ssh-add(1) and ssh-agent(1) manual pages, there
may be a few things you might be interested in.

> Kind regards,

Kind regards to you too,
-- 
Étienne Mollier 

Re: issues with stretch, issue 2 from many

[Brian]

On Tue 27 Nov 2018 at 13:52:25 +0100, Ionel Mugurel Ciobîcă wrote:

> Dear all,
> 
> I have issues with stretch, to many to count...
> This one will focus on the window manager startup.
> 
> I did a fresh install of Debian stretch using net install disk.
> I use Debian (and Linux) from 1997. In all this time I used fvwm2 as
> windows manager. I also used Unix in 1995-1996 with fvwm2.
> 
> So after the installation, I edit the file $HOME/.xsession
> and I added as last line fvwm2.

You could show us your .xsession.

> I also made the x-window-manager point
> to fvwm2. 

That should have been done for you. startx should (without .xsession}
bring up fvwm.

>   When I login the .xsession is not read, like it was done
> before for older releases, but fvwm is started. After many

How do you know it is not read? (That's a different question from asking
why it was not acted on).

> permutations I found out that if I rename the .xsession into
> .xsessionrc then the file is read, but then the fvwm is started twice,
> one after each other. In other words after I exit fvwm it will enter
> again in fvwm, but the second time without the ssh-agent and other
> things.

Xsession(5) describes what .xsessionrc is used for. Does your use fit
the intended use? Or are you abusing the file's intended purpose?

> Question 2.1: Why .xsession is not read and .xsessionrc is read?
> Question 2.2: Who starts the second call of fvwm? If I comment out the
> fvwm call in .xsession(rc) then the fvwm doesn't use the ssh-agent
> (for example). At the moment I simply deleted x-window-manager, so
> when I logout from fvwm I get a error/warning instead of a new fvwm
> session.
> 
> I tried both kdm and xdm as display managers. It will make no
> difference. I use fvwm 2.6.7. I have Linux 4.9.0-8-amd64.
> 
> I would appreciate any hint.

Make it simple to begin with. Type startx (no .xsession) and go from
there when you have that working.

-- 
Brian.

RE: stretch update overwrites nano file

[Bonno Bloksma]

Hi,

[...]
 with timestamp Jul 16 2014 are gone and my default.nanorc file of 
 a later date is gone as well.
 There are now around 40 files with timestamp Jan 11 2017.
[...]
>> As you say, anything in /usr/share/ is under the control of the 
>> packaging system and in, this case, "my default.nanorc" is not the 
>> user's default.nanorc but the system's. It can do what it wants with 
>> it. There is no bug here.
 
>> Correct. Why should there be any warning when the packaging system is 
>> only doing what it is designed to do? A user would alter nano's 
>> behaviour in $HOME.

> For the OP who probably isn't reading the list... The man pages for nano 
> (command "man nano") says at end "See Also nanorc", and "man nanorc" says:
I do read this list ;-)

>   During startup, nano will first read the system-wide settings, from
>  /etc/nanorc (the exact path might be different), and then the user-
>  specific settings, from ~/.nanorc.
> So, the correct file to customise nano settings is either of those two files.

Yup, I simply put my default.nanorc file back into the /usr/share/nano dir. I 
want it to be a system wide default as the current default is "a bit sparse" ;-)
I now better understand the logic why my default file got replaced. Still it 
would have been better if there was some kind of warning but I understand the 
logic and I can live with it. :-)
Thanks for the explanation

Bonno Bloksma

Re: Looking for a "friendly" e-mail service

[Celejar]

On Tue, 27 Nov 2018 15:04:48 +1100
Erik Christiansen  wrote:

> On 26.11.18 21:12, Celejar wrote:
> > On Mon, 26 Nov 2018 09:37:21 -0500
> > Mark Neidorff  wrote:
> > > Now, I don't like the webmail interfaces and the limited storage for old 
> > 
> > Limited storage? Who - big or small player - offers unlimited storage
> > for old emails?
> 
> There are various values for old and limited, in reality. When I'm out
> of town for a fortnight, there's usually 1500 to 2k emails piled up on
> the ISP's mailhost. Fortunately only a small subset of them are over 1
> MB in size.
> 
> It is fortunately rare for ISPs to block multi-megabyte emails now that
> we've left the old millennium behind, as I'm in the process of building,
> and local authorities, building surveyors, fire authorities, etc.,
> mostly issue their documents by email now.
> 
> Still, a few hundred MB usually does it for the fortnight, and the
> longer absence over the new year is an email drought, so size would be
> similar.
> 
> Those who leave read mail on the ISP's mailhost, due to accessing from
> multiple client hosts, are at greater risk of exceeding their quota, and
> would naturally look for some extra, I figure.

Understood. But the big players - Gmail, Yahoo - are probably the ones
offering the largest amount of storage, whether you're accessing the
mail via POP3 / IMAP or the webmail interface.

Celejar

Re: VLC doesn't shutdown when closed

[Gary Dale]

On 2018-11-27 3:22 a.m., Curt wrote:

On 2018-11-27, Gary Dale  wrote:


If you read the other discussion, the problem seems to be related with
what controls you have added to the interface. If you just use the stock
interface, it works. Adding speed controls creates the issue.


I added the 'faster' and 'slower' speed controls to the time toolbar in
vlc, started a video, stopped it by clicking the upper right-hand X of
the video's graphical window, but failed to reproduce the symptoms
you've described.


The VLC maintainers appear to have finally fixed the problem.

Re: issues with stretch, issue 2 from many

[Greg Wooledge]

On Tue, Nov 27, 2018 at 10:32:24AM -0600, David Wright wrote:
> > Question 2.1: Why .xsession is not read and .xsessionrc is read?
> 
> Don't know. But you haven't posted how you start X.

He said he used "xdm and kdm", if I recall correctly.  Sounds like he
is switching things around randomly and frequently, instead of focusing
on one setup and describing it in detail.

> I use startx myself.

Same.

> But AIUI Debian has put a lot of effort into
> making it possible for X server sessions to end up in the same
> configuration whether they were started from a VC or a DM. Your using
> .xsessionrc sounds as if you might be working around some other
> "misconfiguration" that's happened to work until now. It might even
> have been like that since the "Great X Reorganisation" back in the
> days of slink.

My understanding is .xsessionrc was created in order to give users a
modicum of control over their own lives if they happen to use GNOME.
Since normally a gdm3/GNOME session will ignore everything in the
user's .xsession file, Debian created this other file that can be used
with GNOME.  Or with sddm/KDE, or lightdm, or xdm, or whatever other
bizarre display managers may appear in the future and screw everything
up even more.

I documented everything I could figure out about .xsessionrc and friends
at .  There are definitely holes in my
knowledge when it comes to Desktop Environments (GNOME, KDE, and their
ilk), because I do not use them.  The more I learn about them, the less
I want to be anywhere near one.  Ever.

If the OP, or anyone else, wants help understanding how their X startup
works, we need a few concrete pieces of information before we can even
begin:

1) What version of Debian are you using?

2) How do you log in to your computer?  If it's a display manager
   (graphical login), which one is it?  If you need help figuring this
   out, see below.

3) How do you start X?  (Do you explicitly type a command, or is it started
   automatically by your graphical login?)


Figuring out which display manager you are using:

This is freakin' hard.  Way harder than it needs to be, in my opinion,
but I don't have any specific suggestions for how to remedy this, short
of the display managers individually choosing to identify themselves
in some way on the screen.

There are two ways I can think of to approach the situation.  The first
is to ask the Debian package manager which display manager(s) are
installed.  This basically means you need to know the names of ALL of
the common display manager packages, so you can ask for them all.

As a shortcut, however, we can take advantage of the fact that most of
them end with the letters "dm", or with the letters "dm" followed by
a single digit.  Thus:

# dpkg -l \*dm \*dm\[0-9]
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
un  gdm3 (no description available)
ii  kde-config-sdd 4:5.8.4-1amd64KCM module for SDDM
un  mdadm(no description available)
ii  sddm   0.14.0-4+deb amd64modern display manager for X11

On this system, it looks like sddm is installed.  So that's probably
the display manager that's in use.

The second approach is to log out of your X session so that the display
manager is actually running.  Then login on the text console (by pressing
Ctrl-Alt-F2), or by ssh-ing into the computer, and ask the system which
display manager processes are running.  Again, this requires that you
have some knowledge of the *names* of these processes, so you know what
to look/ask for.

# ps -ef | grep gdm
root 32374 32342  0 12:01 pts/000:00:00 grep gdm

Nope.

# ps -ef | grep lightdm
root 32376 32342  0 12:01 pts/000:00:00 grep lightdm

Nope.

# ps -ef | grep sddm
root   603 1  0 Nov02 ?00:00:00 /usr/bin/sddm
root   683   603  0 Nov02 tty7 00:38:45 /usr/lib/xorg/Xorg -nolisten 
tcp -auth /var/run/sddm/{2b3b5bd9-8457-4fd5-b80d-b4c78b6bbc85} -background none 
-noreset -displayfd 18 vt7
root  1155   603  0 Nov02 ?00:00:00 
/usr/lib/x86_64-linux-gnu/sddm/sddm-helper --socket 
/tmp/sddm-authe24f9403-2eb8-4029-a8c8-83969060da79 --id 2 --start 
/usr/bin/sddm-greeter --socket /tmp/sddm-:0-nWnvBg --theme 
/usr/share/sddm/themes/debian-theme --user sddm --greeter
sddm  1157 1  0 Nov02 ?00:00:00 /lib/systemd/systemd --user
sddm  1158  1157  0 Nov02 ?00:00:00 (sd-pam)
sddm  1160  1155  0 Nov02 ?01:40:22 /usr/bin/sddm-greeter --socket 
/tmp/sddm-:0-nWnvBg --theme /usr/share/sddm/themes/debian-theme
sddm  1168 1  0 Nov02 ?00:00:00 dbus-launch --autolaunch 
5942ce2e232449d09bfb1b98b5b26d87 --binary-syntax --clos

Re: issues with stretch, issue 2 from many

[David Wright]

On Tue 27 Nov 2018 at 13:52:25 (+0100), Ionel Mugurel Ciobîcă wrote:
> I have issues with stretch, to many to count...
> This one will focus on the window manager startup.
> 
> I did a fresh install of Debian stretch using net install disk.
> I use Debian (and Linux) from 1997. In all this time I used fvwm2 as
> windows manager. I also used Unix in 1995-1996 with fvwm2.

Sure. I used fvwm2 explicitly with hamm and slink, maybe even with bo.
But the fact that you still write "2" might indicate that there's
cruft in the system which is doing something unexpected.

> So after the installation, I edit the file $HOME/.xsession
> and I added as last line fvwm2.

I happen not to do it that way; I exec it early in the file so that
it's running while everything else in .xsession comes up. The last
line in .xsession is a wait on the WM's PID.

> I also made the x-window-manager point
> to fvwm2.

I don't understand. Doesn't x-window-manager already point to fvwm2
in /etc/alternatives ?

> When I login the .xsession is not read, like it was done
> before for older releases, but fvwm is started.

Interesting. On my system, ps -ef reveals:

UID PID  PPID   TIME CMD
david  1495  1297   00:00:00 /bin/sh /usr/bin/X11/startx
david  1517  1495   00:00:00 xinit /etc/X11/xinit/xinitrc -- 
/etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /tmp/serverauth.lLPH4nRsUP
david  1518  1517   00:00:33 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty 
-auth /tmp/serverauth.lLPH4nRsUP
david  1524  1517   00:00:00 /bin/bash /home/david/.xsession
david  1577  1524   00:00:01 /usr/bin/fvwm

so what started yours?

> After many
> permutations I found out that if I rename the .xsession into
> .xsessionrc then the file is read, but then the fvwm is started twice,
> one after each other. In other words after I exit fvwm it will enter
> again in fvwm, but the second time without the ssh-agent and other
> things.

Well, it would if you start both fvwm2 and x-window-manager.

> Question 2.1: Why .xsession is not read and .xsessionrc is read?

Don't know. But you haven't posted how you start X.

> Question 2.2: Who starts the second call of fvwm? If I comment out the
> fvwm call in .xsession(rc) then the fvwm doesn't use the ssh-agent
> (for example). At the moment I simply deleted x-window-manager, so
> when I logout from fvwm I get a error/warning instead of a new fvwm
> session.

What sort of error message? I get messages like:

xinit: connection to X server lost
waiting for X server to shut down Server terminated successfully (0). Closing 
log file.
xinit: unexpected signal 15

but they're expected by me as I either typed Ctrl-Alt-Backspace or shutdown.

> I tried both kdm and xdm as display managers. It will make no
> difference. I use fvwm 2.6.7. I have Linux 4.9.0-8-amd64.

I use startx myself. But AIUI Debian has put a lot of effort into
making it possible for X server sessions to end up in the same
configuration whether they were started from a VC or a DM. Your using
.xsessionrc sounds as if you might be working around some other
"misconfiguration" that's happened to work until now. It might even
have been like that since the "Great X Reorganisation" back in the
days of slink.

Cheers,
David.

Permissions in setuid-root-program

[Christoph Pleger]

Hello,

I want to ask for possible reasons why a program with setuid-root file 
permission (or a program with special Linux capabilities), when it is 
called by an unprivileged user from PAM module pam_exec, behaves very 
different from when it is called by an unprivileged user from the 
command line.


So far, I had the following differences:

1. When I do not give the setuid-root file permission to the program, 
but give it the Linux cap_setuid capability, that works from the command 
line, but with pam_exec the program is not run at all, with error 
"Operation not permitted".


2. For further execution of the program, not only the effective, but 
also the real UID hast to be 0. From the command line, this works when I 
use setuid(0) in the program code, but with pam_exec, setuid(0) fails to 
change the real UID and I have to use setreuid(0,0) instead.


3. Though real and effective UID are 0,  I still get errors like 
"Permission denied" and "Operation not permitted" when the program is 
called from pam_exec. First, this happened when executing external 
command lvcreate from my setuid-root program, and after I solved that 
now by using lvm dbus library calls instead, I even get an "Operation 
not permitted" when doing a simple chown() on a directory in the local 
filesystem. Of course, this all works perfectly when I start my program 
from the command line.


So, I would like to know how it is possible that operations fail with 
"Permission denied" or "Operation not permitted" though both getuid() 
and geteuid() return 0.


Regards
  Christoph

Re: Looking for a "friendly" e-mail service

[John Hasler]

Gene writes:
> No for everything that clamav gives a clean bill of health, it tells
> kmail to go get the mail when a mailfile in /var/mail is closed after
> procmail writes it there. Kmail looks at the headers and if spamd said
> it was spam, sorts it to the spam folder. procmail takes care of the
> viri so kmail never sees it at all.

> If not spam, it gets sorted into the appropriate mail folder by kmail.
> All triggered by inotifywait exiting with the name of the file, bash
> then takes the correct action and restarts inotifywait, all in a
> millisecobd or so.  That bash script I called mailwatcher.

You've reinvented parts of Mailagent and Exim.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

[SOLVED]: openvpn over ipv6 /65

[tony]

On 27/11/2018 15:03, Reco wrote:

> In conclusion, your current NAT66 setup is probably the best you can
> achieve without a risk to your VPS or your sanity ;)
> 
OK Reco, that's great. I'm announcing a valid IPv6 address, so it's
achieving its objective. I can route traffic from any of my IOT boxes
over IPv6 to any other box. I can include a marker in any message to
indicate its origin. I can then communicate with them via their native
IPv6 addresses. I don't think I can want for any more, so I've marked
this as [SOLVED].

My next task is to write this all up, and try to understand what we've
been doing.

Thanks a million for your assistance, without which I'd still be
floundering.

Cheers, Tony.

Re: Looking for a "friendly" e-mail service

[Gene Heskett]

On Tuesday 27 November 2018 08:41:32 rhkra...@gmail.com wrote:

> On Monday, November 26, 2018 09:51:49 PM Gene Heskett wrote:
> > I even wrote a script to couple kmail so the incoming mail only
> > exists few a few milliseconds in /var/mail.
>
> I don't understand -- what is your script doing?  Is it doing it only
> for spam?

No for everything that clamav gives a clean bill of health, it tells 
kmail to go get the mail when a mailfile in /var/mail is closed after 
procmail writes it there. Kmail looks at the headers and if spamd said 
it was spam, sorts it to the spam folder. procmail takes care of the 
viri so kmail never sees it at all.

If not spam, it gets sorted into the appropriate mail folder by kmail. 
All triggered by inotifywait exiting with the name of the file, bash 
then takes the correct action and restarts inotifywait, all in a 
millisecobd or so.  That bash script I called mailwatcher. An older 
version that might need tweaking for you system & names is on my web 
page in the sig. Be my guest.
>
> > I'm a lazy cuss, let the computer
> > handle all that stuff, that is what I built it for, to work FOR me.
> > And its been very happy being my slave.



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Fwd: openvpn over ipv6 /65

[Reco]

On Tue, Nov 27, 2018 at 01:56:34PM +0100, tony wrote:
> >> If I remove the line
> >> -A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
> >> 2a03:9800:10:54::2
> >> I lose any ipv6 routing
> > 
> > Strictly speaking, that's expected. Outside world does not know about
> > your network topology. What is does know is to send packets to
> > 2a03:9800:10:54::1 (*not* :2) in hope of reaching your :8000::/65.
> > The problem is - how your IPv6 gateway (54::1) can possibly know that
> > your custom subnet (:8000::/65) is reachable if you have not announced a
> > route?
> > 
> > That's something that I need to think about.
> 
> thanks very much for spending so much time on my problem.

So, I thought about all this, and came to the following:

1) You can try announcing your own /65 route, but there's 100% chance
that your IPv6 gateway will reject it. I'd do it too if I was your VPS
provider.

2) Currently you have two different network segments - one on eth0, and
another one on tun0 (that one).
Even if you make your openvpn encapsulate L2 traffic (don't), unless you
want to risk losing all network connectivity to your VPS by bridging
eth0 and tun0 *and* hacking openvpn scripts - I see no easy way to
bridge those two segments.

3) Likewise, you *could* put your eth0 in the promiscous mode, and write
some set of netfilter rules to traverse the gap between eth0 and tun0,
but that's wrong on so many levels that I don't know where to begin to
describe it.

In conclusion, your current NAT66 setup is probably the best you can
achieve without a risk to your VPS or your sanity ;)

Reco

Re: Looking for a "friendly" e-mail service

[rhkramer]

On Monday, November 26, 2018 09:51:49 PM Gene Heskett wrote:
> I even wrote a script to couple kmail so the incoming mail only exists
> few a few milliseconds in /var/mail. 

I don't understand -- what is your script doing?  Is it doing it only for 
spam?




> I'm a lazy cuss, let the computer
> handle all that stuff, that is what I built it for, to work FOR me. And
> its been very happy being my slave.

issues with stretch, issue 2 from many

[Ionel Mugurel Ciobîcă]

Dear all,

I have issues with stretch, to many to count...
This one will focus on the window manager startup.

I did a fresh install of Debian stretch using net install disk.
I use Debian (and Linux) from 1997. In all this time I used fvwm2 as
windows manager. I also used Unix in 1995-1996 with fvwm2.

So after the installation, I edit the file $HOME/.xsession
and I added as last line fvwm2. I also made the x-window-manager point
to fvwm2. When I login the .xsession is not read, like it was done
before for older releases, but fvwm is started. After many
permutations I found out that if I rename the .xsession into
.xsessionrc then the file is read, but then the fvwm is started twice,
one after each other. In other words after I exit fvwm it will enter
again in fvwm, but the second time without the ssh-agent and other
things.

Question 2.1: Why .xsession is not read and .xsessionrc is read?
Question 2.2: Who starts the second call of fvwm? If I comment out the
fvwm call in .xsession(rc) then the fvwm doesn't use the ssh-agent
(for example). At the moment I simply deleted x-window-manager, so
when I logout from fvwm I get a error/warning instead of a new fvwm
session.

I tried both kdm and xdm as display managers. It will make no
difference. I use fvwm 2.6.7. I have Linux 4.9.0-8-amd64.

I would appreciate any hint.

Thank you.

Kind regards,
 Ionel

issues with stretch, part 1 of many

[Ionel Mugurel Ciobîcă]

Dear all,

I have many issues with stretch which I cannot figure it out. I will
post one at the time, to keep it clear and simple.

I use Debian since 1997. I never had an issue with any release, except
stretch. I installed fresh using net install disk. The install went OK
(except I was forced to chose a wrong timezone (I was not asked about
the continent), but that I fix after installation).

The first question I want to ask relates to ssh, ssh-ask and
ssh-agent. When I ssh to another computer I am asked "Allow use of key
id_rsa? Key fingerprint ..." If I uninstall all ssh-ask programs I
simply can't use the ssh-agent anymore and I am prompted for password.
I try ssh-ask, ssh-ask-fullscreen, ssh-ask-gnome and the similar from
kde. I check the /etc/ssh/ssh_config and /etc/ssh/sshd_config for
anything that may relate to this. The only think coming close are:
UsePAM yes
ChallengeResponseAuthentication no

Is there something I overlook?

To be clear, I do not want to be asked if I allow the use of a key, I
just want this to be assumed yes, as it was the case in the past. 

So, I run Linux 4.9.0-8-amd64, Debian 9u6. ssh is openssh_7.4p1,
openssl 1.0.2l ssh-agent is started in $HOME/.xsessionrc as:
eval `ssh-agent -s`

Thank you for any hint.

Kind regards,
 Ionel

Re: issues with stretch, part 1 of many

[Ionel Mugurel Ciobîcă]

On 27-11-2018, at 13h 33'55", Ionel Mugurel Ciobîcă wrote about "issues with 
stretch, part 1 of many"
> 
> 
> Dear all,
> 
> I have many issues with stretch which I cannot figure it out. I will
> post one at the time, to keep it clear and simple.
> 
> I use Debian since 1997. I never had an issue with any release, except
> stretch. I installed fresh using net install disk. The install went OK
> (except I was forced to chose a wrong timezone (I was not asked about
> the continent), but that I fix after installation).
> 
> The first question I want to ask relates to ssh, ssh-ask and
> ssh-agent. When I ssh to another computer I am asked "Allow use of key
> id_rsa? Key fingerprint ..." If I uninstall all ssh-ask programs I
> simply can't use the ssh-agent anymore and I am prompted for password.
> I try ssh-ask, ssh-ask-fullscreen, ssh-ask-gnome and the similar from
> kde. I check the /etc/ssh/ssh_config and /etc/ssh/sshd_config for
> anything that may relate to this. The only think coming close are:
> UsePAM yes
> ChallengeResponseAuthentication no
> 
> Is there something I overlook?
> 
> To be clear, I do not want to be asked if I allow the use of a key, I
> just want this to be assumed yes, as it was the case in the past. 
> 
> So, I run Linux 4.9.0-8-amd64, Debian 9u6. ssh is openssh_7.4p1,
> openssl 1.0.2l ssh-agent is started in $HOME/.xsessionrc as:
> eval `ssh-agent -s`
> 

A hint of the followup questions already is given by the ssh-agent the
first time when the passphrase is introduced, by announcing: "Enter
passphrase for id_rsa (will confirm each use):".

I do not want to confirm each usage. My .xsession(rc) contains many
calls of "xterm -e ssh ..." using -geometry to position the xterms,
and all of those "allow use of key..." questions agglomerates on the
same place, one on top of each other. I do not understand conceptually
why this would be desired (to be asked again and again). The point of
ssh-agent was to make it simpler, not more complicated. If I want to
be asked, I will not use the agent, so I can input password when
connecting...


Kind regards,
 Ionel

Re: Fwd: openvpn over ipv6 /65

[tony]

On 27/11/2018 13:34, Reco wrote:
>   Hi.
> 
> On Tue, Nov 27, 2018 at 01:20:25PM +0100, tony wrote:
>> On 27/11/2018 12:44, Reco wrote:
>>> Hi.
>>>
>>> On Tue, Nov 27, 2018 at 12:26:03PM +0100, tony wrote:
 OK, that fixed it, thanks. Almost there. I had expected the host's
 openVPN ip (2a03:9800:10:54:8000::1000) to propagate, but I'm seeing my
 server's address:

 tony@tony-fr:~$ dig +short any myip.opendns.com @resolver1.opendns.com
 2a03:9800:10:54::2

 Is that fixable?
>>>
>>> Probably. My suspicion is that openvpn has configured NAT66 for you,
>>> along with the routing.
>>> Can I see the result of "ip6tables-save" from your openvpn server?
>>
>> OK:
>> root@shell:~# ip6tables-save
>> # Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
>> *nat
>> :PREROUTING ACCEPT [12346:1595144]
>> :INPUT ACCEPT [1726:141923]
>> :OUTPUT ACCEPT [743:66648]
>> :POSTROUTING ACCEPT [743:66648]
>> -A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
>> 2a03:9800:10:54::2
> 
> Yep. Good old NAT, in this case in IPv6 form. What they call NAT66.
> 
> 
>> If I remove the line
>> -A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
>> 2a03:9800:10:54::2
>> I lose any ipv6 routing
> 
> Strictly speaking, that's expected. Outside world does not know about
> your network topology. What is does know is to send packets to
> 2a03:9800:10:54::1 (*not* :2) in hope of reaching your :8000::/65.
> The problem is - how your IPv6 gateway (54::1) can possibly know that
> your custom subnet (:8000::/65) is reachable if you have not announced a
> route?
> 
> That's something that I need to think about.

thanks very much for spending so much time on my problem.

Re: Fwd: openvpn over ipv6 /65

[Reco]

Hi.

On Tue, Nov 27, 2018 at 01:20:25PM +0100, tony wrote:
> On 27/11/2018 12:44, Reco wrote:
> > Hi.
> > 
> > On Tue, Nov 27, 2018 at 12:26:03PM +0100, tony wrote:
> >> OK, that fixed it, thanks. Almost there. I had expected the host's
> >> openVPN ip (2a03:9800:10:54:8000::1000) to propagate, but I'm seeing my
> >> server's address:
> >>
> >> tony@tony-fr:~$ dig +short any myip.opendns.com @resolver1.opendns.com
> >> 2a03:9800:10:54::2
> >>
> >> Is that fixable?
> > 
> > Probably. My suspicion is that openvpn has configured NAT66 for you,
> > along with the routing.
> > Can I see the result of "ip6tables-save" from your openvpn server?
> 
> OK:
> root@shell:~# ip6tables-save
> # Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
> *nat
> :PREROUTING ACCEPT [12346:1595144]
> :INPUT ACCEPT [1726:141923]
> :OUTPUT ACCEPT [743:66648]
> :POSTROUTING ACCEPT [743:66648]
> -A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
> 2a03:9800:10:54::2

Yep. Good old NAT, in this case in IPv6 form. What they call NAT66.


> If I remove the line
> -A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
> 2a03:9800:10:54::2
> I lose any ipv6 routing

Strictly speaking, that's expected. Outside world does not know about
your network topology. What is does know is to send packets to
2a03:9800:10:54::1 (*not* :2) in hope of reaching your :8000::/65.
The problem is - how your IPv6 gateway (54::1) can possibly know that
your custom subnet (:8000::/65) is reachable if you have not announced a
route?

That's something that I need to think about.

Reco

Re: Fwd: openvpn over ipv6 /65

[tony]

On 27/11/2018 12:44, Reco wrote:
>   Hi.
> 
> On Tue, Nov 27, 2018 at 12:26:03PM +0100, tony wrote:
>> OK, that fixed it, thanks. Almost there. I had expected the host's
>> openVPN ip (2a03:9800:10:54:8000::1000) to propagate, but I'm seeing my
>> server's address:
>>
>> tony@tony-fr:~$ dig +short any myip.opendns.com @resolver1.opendns.com
>> 2a03:9800:10:54::2
>>
>> Is that fixable?
> 
> Probably. My suspicion is that openvpn has configured NAT66 for you,
> along with the routing.
> Can I see the result of "ip6tables-save" from your openvpn server?
> 
>

OK:
root@shell:~# ip6tables-save
# Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
*nat
:PREROUTING ACCEPT [12346:1595144]
:INPUT ACCEPT [1726:141923]
:OUTPUT ACCEPT [743:66648]
:POSTROUTING ACCEPT [743:66648]
-A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
2a03:9800:10:54::2
COMMIT
# Completed on Tue Nov 27 11:50:18 2018
# Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
*raw
:PREROUTING ACCEPT [2472612:400710422]
:OUTPUT ACCEPT [3139829:2958344820]
COMMIT
# Completed on Tue Nov 27 11:50:18 2018
# Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
*mangle
:PREROUTING ACCEPT [2472612:400710422]
:INPUT ACCEPT [2456362:396255430]
:FORWARD ACCEPT [5708:3070874]
:OUTPUT ACCEPT [3139831:2958345100]
:POSTROUTING ACCEPT [3145539:2961415974]
COMMIT
# Completed on Tue Nov 27 11:50:18 2018
# Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [165:76753]
:OUTPUT ACCEPT [3135467:2956504072]
-A INPUT -i tun+ -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4000 -j ACCEPT
-A INPUT -s 2001:8b0:ff60:6a91::/64 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p tcp -m tcp --sport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --sport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --sport 53 -j ACCEPT
-A INPUT -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 123 -j ACCEPT
-A INPUT -s ::1/128 -d ::1/128 -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "ip6tables denied: "
--log-level 7
-A INPUT -j DROP
-A INPUT -p ipv6-icmp -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 2a03:9800:10:54::/64 -i tap0 -o eth0 -j ACCEPT
-A FORWARD -p ipv6-icmp -j ACCEPT
COMMIT
# Completed on Tue Nov 27 11:50:18 2018


If I remove the line
-A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
2a03:9800:10:54::2
I lose any ipv6 routing

Re: Fwd: openvpn over ipv6 /65

[Reco]

Hi.

On Tue, Nov 27, 2018 at 12:26:03PM +0100, tony wrote:
> OK, that fixed it, thanks. Almost there. I had expected the host's
> openVPN ip (2a03:9800:10:54:8000::1000) to propagate, but I'm seeing my
> server's address:
> 
> tony@tony-fr:~$ dig +short any myip.opendns.com @resolver1.opendns.com
> 2a03:9800:10:54::2
> 
> Is that fixable?

Probably. My suspicion is that openvpn has configured NAT66 for you,
along with the routing.
Can I see the result of "ip6tables-save" from your openvpn server?

Reco

Re: Fwd: openvpn over ipv6 /65

[tony]

On 27/11/2018 11:55, Reco wrote:
> On Tue, Nov 27, 2018 at 11:53:07AM +0100, tony wrote:
>> On 27/11/2018 11:43, Reco wrote:
>>> Hi.
>>>
>>> On Tue, Nov 27, 2018 at 11:19:12AM +0100, tony wrote:
>> push "route-ipv6 2a03:9800:10:54:8000::/65"
>> push "route-ipv6 2000::/3"
>> push "redirect-gateway def1 bypass-dhcp"
>
> Remove these. Use this instead:
>
> push "redirect-gateway def1"
> push "route-ipv6 ::/0 metric 99"

 Well, there's an improvement: I'm now able to resolve v6 addresses with
 the VPN up, presumably because IPv6 forwarding now being enabled, BUT,
 the remote end is still seeing the native V6 address.

 I'm seeing this in my host's OVPN log:
 Tue Nov 27 10:24:58 2018 us=429309 PUSH: Received control message:
 'PUSH_REPLY,redirect-gateway def1,route-ipv6 ::/0 metric
 99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
 208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
 85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
 120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
 2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 2,cipher
 AES-256-GCM'
 Tue Nov 27 10:24:58 2018 us=429418 Options error: route-ipv6 parameter
 gateway 'metric' must be a valid address
 Tue Nov 27 10:24:58 2018 us=429472 Note: option tun-ipv6 is ignored
 because modern operating systems do not need special IPv6 tun handling
 anymore.

 I'm assuming it doesn't like the ::/0 address, nor do I understand that.
>>>
>>> Nah, it does not like "metric" part, which is crucial here.
>>> But try this:
>>>
>>> push "redirect-gateway def1 ipv6"
>>>
>>>
>> Nope:
> 
> Ok, keep 
> 
> push "redirect-gateway def1"
> 
> but remove 
> 
> push "route-ipv6 ::/0 metric 99"
> 
> Reco
> 

OK, that fixed it, thanks. Almost there. I had expected the host's
openVPN ip (2a03:9800:10:54:8000::1000) to propagate, but I'm seeing my
server's address:

tony@tony-fr:~$ dig +short any myip.opendns.com @resolver1.opendns.com
2a03:9800:10:54::2

Is that fixable?

Cheers, Tony

Re: stretch update overwrites nano file

[Brian]

On Mon 26 Nov 2018 at 22:08:07 -0500, Cindy-Sue Causey wrote:

> On 11/26/18, David Wright  wrote:
> > On Mon 26 Nov 2018 at 16:31:38 (+), Bonno Bloksma wrote:
> >> What I just DID notice is that the upgrade replaced ALL nanorc files in
> >> the /usr/share/nano/ directory. All ca. 30 default files with timestamp
> >> Jul 16 2014 are gone and my default.nanorc file of a later date is gone as
> >> well.
> >> There are now around 40 files with timestamp Jan 11 2017.
> >
> > AIUI those files are part of the nano package, so the upgrade upgrades
> > them. It would be nice if one could substitute one's own foo.nanorc
> > file in a location like /etc/nano/ but I don't think the code for that
> > has been written into the program.
> 
> 
> I suppose it would still wipe out a symlink that was hooked to
> something under something like ~/.something. In a perfect world, it
> would say, "Ewww, I don't know what that is," and keep moving without
> touching it..

A non-package file is left untouched by a package upgrade. An admin could
handle an edited package file with dpkg-divert.

  File  diversions are a way of forcing dpkg(1) not to install a file
  into its location, but to a diverted location. Diversions can be used
  through the Debian package scripts to move a file away when it causes
  a conflict. System administrators can also use it to override some
  package's configuration file, or whenever some files (which aren't
  marked as “conffiles”) need to be preserved by dpkg, when installing a
  newer version of a package which contains those files.

-- 
Brian.

Re: Fwd: openvpn over ipv6 /65

[Reco]

On Tue, Nov 27, 2018 at 11:53:07AM +0100, tony wrote:
> On 27/11/2018 11:43, Reco wrote:
> > Hi.
> > 
> > On Tue, Nov 27, 2018 at 11:19:12AM +0100, tony wrote:
>  push "route-ipv6 2a03:9800:10:54:8000::/65"
>  push "route-ipv6 2000::/3"
>  push "redirect-gateway def1 bypass-dhcp"
> >>>
> >>> Remove these. Use this instead:
> >>>
> >>> push "redirect-gateway def1"
> >>> push "route-ipv6 ::/0 metric 99"
> >>
> >> Well, there's an improvement: I'm now able to resolve v6 addresses with
> >> the VPN up, presumably because IPv6 forwarding now being enabled, BUT,
> >> the remote end is still seeing the native V6 address.
> >>
> >> I'm seeing this in my host's OVPN log:
> >> Tue Nov 27 10:24:58 2018 us=429309 PUSH: Received control message:
> >> 'PUSH_REPLY,redirect-gateway def1,route-ipv6 ::/0 metric
> >> 99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
> >> 208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
> >> 85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
> >> 120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
> >> 2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 2,cipher
> >> AES-256-GCM'
> >> Tue Nov 27 10:24:58 2018 us=429418 Options error: route-ipv6 parameter
> >> gateway 'metric' must be a valid address
> >> Tue Nov 27 10:24:58 2018 us=429472 Note: option tun-ipv6 is ignored
> >> because modern operating systems do not need special IPv6 tun handling
> >> anymore.
> >>
> >> I'm assuming it doesn't like the ::/0 address, nor do I understand that.
> > 
> > Nah, it does not like "metric" part, which is crucial here.
> > But try this:
> > 
> > push "redirect-gateway def1 ipv6"
> > 
> > 
> Nope:

Ok, keep 

push "redirect-gateway def1"

but remove 

push "route-ipv6 ::/0 metric 99"

Reco

Re: Fwd: openvpn over ipv6 /65

[tony]

On 27/11/2018 11:43, Reco wrote:
>   Hi.
> 
> On Tue, Nov 27, 2018 at 11:19:12AM +0100, tony wrote:
 push "route-ipv6 2a03:9800:10:54:8000::/65"
 push "route-ipv6 2000::/3"
 push "redirect-gateway def1 bypass-dhcp"
>>>
>>> Remove these. Use this instead:
>>>
>>> push "redirect-gateway def1"
>>> push "route-ipv6 ::/0 metric 99"
>>
>> Well, there's an improvement: I'm now able to resolve v6 addresses with
>> the VPN up, presumably because IPv6 forwarding now being enabled, BUT,
>> the remote end is still seeing the native V6 address.
>>
>> I'm seeing this in my host's OVPN log:
>> Tue Nov 27 10:24:58 2018 us=429309 PUSH: Received control message:
>> 'PUSH_REPLY,redirect-gateway def1,route-ipv6 ::/0 metric
>> 99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
>> 208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
>> 85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
>> 120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
>> 2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 2,cipher
>> AES-256-GCM'
>> Tue Nov 27 10:24:58 2018 us=429418 Options error: route-ipv6 parameter
>> gateway 'metric' must be a valid address
>> Tue Nov 27 10:24:58 2018 us=429472 Note: option tun-ipv6 is ignored
>> because modern operating systems do not need special IPv6 tun handling
>> anymore.
>>
>> I'm assuming it doesn't like the ::/0 address, nor do I understand that.
> 
> Nah, it does not like "metric" part, which is crucial here.
> But try this:
> 
> push "redirect-gateway def1 ipv6"
> 
> 
Nope:

Tue Nov 27 11:48:03 2018 us=205080 PUSH: Received control message:
'PUSH_REPLY,redirect-gateway def1 ipv6,route-ipv6 ::/0 metric
99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher
AES-256-GCM'
Tue Nov 27 11:48:03 2018 us=205203 Options error: route-ipv6 parameter
gateway 'metric' must be a valid address

Sorry

Re: modprobe bbswitch fails

[Alexander V. Makartsev]

On 27.11.2018 2:03, Johann Spies wrote:
> Trying to get my nvidia-card to work properly following tutorials like
> https://www.pcsuggest.com/install-and-configure-nvidia-optimus-with-bumblebee-in-debian/
> and
> https://www.pcsuggest.com/nvidia-optimus-troubleshooting-in-debain-kali-linux-ubuntu/
> I fail to get pass the step where I have to do
> "sudo modprobe bbswitch load_state=0"
>
> It ends in
>
> bbswitch: No suitable _DSM call found
> modprobe: ERROR: could not insert 'bbswitch': no such device
>
> This is on a HP Zbook 15 laptop which I recently bought with a NVIDIA
> GK107GLM [ Quadro K1100M] VGA compatable controller.
>
> I have searched the internet for a solution but nothing so far worked
> for me.
> Inter alia: This 2015 bug
>  and this
> 2013 discussion
> 
>  and
> https://wiki.debian.org/NvidiaGraphicsDrivers/Optimus#Identification.
> 
>
> Most of the information I found, was old and referred to bugs in older
> kernels.
> I have 4.18.0-2-amd64 #1 SMP on my system.
>
> Any idea about the way forward?
>
> Regards
> Johann
>
>
>
>
> -- 
> Because experiencing your loyal love is better than life itself,
> my lips will praise you.  (Psalm 63:3)
I suggest to check if your laptop has latest Firmware\BIOS update
installed. That is first thing I would check if I got similar error message.
Update it to the latest one provided by HP support website.
Also check if there are some settings in BIOS, saying Optimus or Hybrid
Graphics that could be tweaked.

Check out similar bug report on GitHub [1]. Some people reported they
fixed it by installing 4.19 kernel, which probably contain more
compatibility fixes for exotic hardware.

[1] https://github.com/Bumblebee-Project/bbswitch/issues/160

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄ 

Re: Fwd: openvpn over ipv6 /65

[Reco]

Hi.

On Tue, Nov 27, 2018 at 11:19:12AM +0100, tony wrote:
> >> push "route-ipv6 2a03:9800:10:54:8000::/65"
> >> push "route-ipv6 2000::/3"
> >> push "redirect-gateway def1 bypass-dhcp"
> > 
> > Remove these. Use this instead:
> > 
> > push "redirect-gateway def1"
> > push "route-ipv6 ::/0 metric 99"
> 
> Well, there's an improvement: I'm now able to resolve v6 addresses with
> the VPN up, presumably because IPv6 forwarding now being enabled, BUT,
> the remote end is still seeing the native V6 address.
> 
> I'm seeing this in my host's OVPN log:
> Tue Nov 27 10:24:58 2018 us=429309 PUSH: Received control message:
> 'PUSH_REPLY,redirect-gateway def1,route-ipv6 ::/0 metric
> 99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
> 208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
> 85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
> 120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
> 2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 2,cipher
> AES-256-GCM'
> Tue Nov 27 10:24:58 2018 us=429418 Options error: route-ipv6 parameter
> gateway 'metric' must be a valid address
> Tue Nov 27 10:24:58 2018 us=429472 Note: option tun-ipv6 is ignored
> because modern operating systems do not need special IPv6 tun handling
> anymore.
> 
> I'm assuming it doesn't like the ::/0 address, nor do I understand that.

Nah, it does not like "metric" part, which is crucial here.
But try this:

push "redirect-gateway def1 ipv6"


> Please indulge my ignorance a little longer; I feel we're getting there.

Sure. One cannot learn unless one's doing.

Reco

Fwd: openvpn over ipv6 /65

[tony]

On 26/11/2018 18:13, Reco wrote:
>   Hi.
> 
> On Mon, Nov 26, 2018 at 05:53:27PM +0100, tony wrote:
 2000::/3 dev tun0 metric 1024  pref medium
 2000::/3 dev tun0 metric 1028  pref medium
>>>
>>> Er, wat? Exterminate this travesty, you should never announce things
>>> like these through openvpn even once, let alone twice. If you really
>>> need to do things like GeoIP spoofing, you should announce an IPv6
>>> default gateway with low metric.
>>>
>> I did wonder about that. I have cobbled together stanzas from many
>> 'tutorials' on the web. the 2000::/3 stanza came from one of those.
>> Someone seemed to think it was a good idea.
> 
> Either that someone solved their own specific task, or did not give it
> much thought. A bad idea.
> 
It actually came from https://community.openvpn.net/openvpn/wiki/IPv6, a
site one would expect to be trustworthy. In fairness it doesn't actually
require this, but in my confusion it just slipped in. Gone now ;)
> 
 I hope that is sufficient information
>>>
>>> More or less. Server's routing table is good, assuming that you have
>>> net.ipv6.conf.all.forwarding set to 1 there.
>>>
>> I assume that's in /etc/sysctl.conf.
> 
> "sysctl net.ipv6.conf.all.forwarding" to check it, and yes,
> /etc/sysctl.conf to implement it.
> 
>> And no, it's commented out, so presumably 0.
> 
> This ain't right. You need your openvpn server to route IPv6 from and to
> you, so set it to 1.
> 
> 
>>> Client's routing table is a mess. What you should get with openvpn
>>> stared is (order may be different):
>>>
> ...
>>> And that means that it's time to see your openvpn's server configuration
>>> file. Can I see one, please?
>>
>> Certainly:
> 
> So, without further ado,
> 
>> proto udp
>> proto udp6
> 
> Choose one here. Either you connect to your openvpn server via IPv4, or
> you do it via IPv6.
> Whatever protocol you encapsulate into openvpn tunnel isn't relevant
> here.
> 
> 
>> dev tun
> 
> L3 tunnel, eh? A good choice, if you ask me.
> 
> 
>> push "route-ipv6 2a03:9800:10:54:8000::/65"
>> push "route-ipv6 2000::/3"
>> push "redirect-gateway def1 bypass-dhcp"
> 
> Remove these. Use this instead:
> 
> push "redirect-gateway def1"
> push "route-ipv6 ::/0 metric 99"

Well, there's an improvement: I'm now able to resolve v6 addresses with
the VPN up, presumably because IPv6 forwarding now being enabled, BUT,
the remote end is still seeing the native V6 address.

I'm seeing this in my host's OVPN log:
Tue Nov 27 10:24:58 2018 us=429309 PUSH: Received control message:
'PUSH_REPLY,redirect-gateway def1,route-ipv6 ::/0 metric
99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 2,cipher
AES-256-GCM'
Tue Nov 27 10:24:58 2018 us=429418 Options error: route-ipv6 parameter
gateway 'metric' must be a valid address
Tue Nov 27 10:24:58 2018 us=429472 Note: option tun-ipv6 is ignored
because modern operating systems do not need special IPv6 tun handling
anymore.

I'm assuming it doesn't like the ::/0 address, nor do I understand that.

Please indulge my ignorance a little longer; I feel we're getting there.

Cheers, Tony

141A318A:SSL routines:tls_process_ske_dhe:dh key too small - who is to blame?

[Hans]

Hi folks, 

since my last update I get this error message from kmail:

141A318A:SSL routines:tls_process_ske_dhe:dh key too small

I understand, that the key is to small since some changes in openssl and due 
to the manual I changed /etc/ssl/openssl.cnf.

This is not all the point,  as I can get it working.

The one thing, I did not understand: If this error appears, who is to blame? 
Is this a problem by the server or is this caused by the provider, who still 
uses too small keys?

Is there a way to avoid this problem, without editing the confoiguration? I am 
thinking of users, who are just using debian, do an update and suddenly get 
into this problem.

Thanks for any short answers.

Best

Hans 

Re: Looking for a "friendly" e-mail service

[Ben Oliver]

On 18-11-26 21:12:19, Celejar wrote:

On Mon, 26 Nov 2018 09:37:21 -0500
Mark Neidorff  wrote:

...


Now, I don't like the webmail interfaces and the limited storage for old


Limited storage? Who - big or small player - offers unlimited storage
for old emails?



My suggestion [0] (a 'small' player) does!

[0] https://www.migadu.com/


signature.asc
Description: PGP signature

Re: VLC doesn't shutdown when closed

[Curt]

On 2018-11-27, Gary Dale  wrote:

> If you read the other discussion, the problem seems to be related with 
> what controls you have added to the interface. If you just use the stock 
> interface, it works. Adding speed controls creates the issue.
>

I added the 'faster' and 'slower' speed controls to the time toolbar in
vlc, started a video, stopped it by clicking the upper right-hand X of
the video's graphical window, but failed to reproduce the symptoms
you've described. 

-- 
He used sentences differently from any other prose writer. He always sounded
like a slightly drunk man who is very melancholy, who has no illusions about
life, who is very strong but whose strength is entirely unnecessary.
--Krasznahorkai on Krúdy