Re: how to prevent security update installation during stretch installation

[deloptes]

David Christensen wrote:

> Why not?

I guess because he's in China and internet costs relatively much there.

Re: update hell

[Default User]

On Jul 31, 2018 23:15, "Ben Caradoc-Davies"  wrote:

On 01/08/18 11:11, Default User wrote:
> I was going to read up on:
> apt-get dist-upgrade -V -s
> But then today, I was able to do a full upgrade, using:
> sudo aptitude -Pvv update
> sudo aptitude -Pvv safe-upgrade
> sudo aptitude -Pvv full-upgrade
> Finally!
> Now, I'm sure using:
> apt-get dist-upgrade -V -s
> would have worked as well, although I thought I read somewhere that mixing
> apt-get and aptitude is not a good idea.

I do not know anything about that.


> Thanks again, Ben.
> And, btw . . .
> dpkg?
> apt-get?
> aptitude?
> apt?

synaptic? No love for synaptic?


> Would Debian please just settle on one, and stick with it?

They do different things at different levels and seem to play nicely
together.

dpkg is the lowest level and manipulates files. apt-get will download
them too, from various sources, and following distribution rules. apt is
a friendlier higher-level command-line interface. aptitude is an ncurses
frontend, good for browsing lists of packages. synaptic is like aptitude
with a GTK frontend.

I only use dpkg and apt-get, but when I started with Debian, I used
synaptic. I came from Red Hat / Fedora, and the only things I miss from
rpm and yum are yum history (with atomic reverts) and the ability to
install multiple concurrent kernel packages without the API versioning
silliness of Debian (which cannot co-install both 4.17.6-2 and 4.17.8-1,
for example, only one linux-image-4.17.0-1-amd64).


Kind regards,

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand




1) Kamaraju, thank you for the pointers to the reading material.

Time to read.

2) Ben, I didn't think to include synapticin the list until after I posted.
I don't normally think of synaptic for general package management; I
normally only use it if I am not sure what package (and dependencies) I am
looking for, or just to browse for something interesting.

I did formerly use apt-get, but now use aptitude instead, because I read
"somewhere" that aptitude has better dependency resolution.

Note: I only use command line aptitude. I find the graphical version of
aptitude to be confusing, non-intuitive, and (for me) not particularly
useful.

Re: update hell

[Ben Caradoc-Davies]

On 01/08/18 11:11, Default User wrote:

I was going to read up on:
apt-get dist-upgrade -V -s
But then today, I was able to do a full upgrade, using:
sudo aptitude -Pvv update
sudo aptitude -Pvv safe-upgrade
sudo aptitude -Pvv full-upgrade
Finally!
Now, I'm sure using:
apt-get dist-upgrade -V -s
would have worked as well, although I thought I read somewhere that mixing
apt-get and aptitude is not a good idea.


I do not know anything about that.


Thanks again, Ben.
And, btw . . .
dpkg?
apt-get?
aptitude?
apt?


synaptic? No love for synaptic?


Would Debian please just settle on one, and stick with it?


They do different things at different levels and seem to play nicely 
together.


dpkg is the lowest level and manipulates files. apt-get will download 
them too, from various sources, and following distribution rules. apt is 
a friendlier higher-level command-line interface. aptitude is an ncurses 
frontend, good for browsing lists of packages. synaptic is like aptitude 
with a GTK frontend.


I only use dpkg and apt-get, but when I started with Debian, I used 
synaptic. I came from Red Hat / Fedora, and the only things I miss from 
rpm and yum are yum history (with atomic reverts) and the ability to 
install multiple concurrent kernel packages without the API versioning 
silliness of Debian (which cannot co-install both 4.17.6-2 and 4.17.8-1, 
for example, only one linux-image-4.17.0-1-amd64).


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: a dh keys question?

[Richard Hector]

On 01/08/18 03:57, Dan Ritter wrote:
> On Tue, Jul 31, 2018 at 11:38:34AM -0400, Karen Lewellen wrote:
>> Hi everyone,
>> While the question seems simple, at least to me, the reason behind it is
>> complicated.  so I am hoping to focus on the question first.
>> During the dh key exchange process, where do the user dh key packets come
>> from software wise?
> 
> You generate a private/public key pair with ssh-keygen, and send
> the public key over to your destination in advance, so that they
> can recognize you.

Yes, but that's not the dh (Diffie-Hellman) key. Diffie-Hellman key
exchange is to generate a one-time session key that is discarded after
the session is finished.

>> I have a problem now where each place I try to visit using my ssh client,
>> and my sftp one, I am getting a dh key exchange failure.
>> using the -v command  is not shedding light on the issue.
>> I am using the same client now to reach another  service, but here  we use a
>> different port from port 22.
>> the error started on the 29th of June, and the company providing my dsl
>> service did claim to have a service issue on that day.
>> However they do not speak Linux let alone anything else Unusual.
>> Thoughts?
> 
> 
> Are you having problems SSHing to all servers that you try, or
> just to one in particular?
> 
> If it's just one, and that one uses a port other than 22, it's
> likely that your DSL company started filtering that port on the
> 29th. 

If it was a simple port filtering issue, then you'd get something like
'Connection Refused' or 'Destination unreachable' or 'Connection timed
out' - you wouldn't get as far as dh key exchange.

I'm not an expert in this, so might have some details wrong, but I think
the gist of it is right. Happy to be corrected.

Richard



signature.asc
Description: OpenPGP digital signature

Re: how to prevent security update installation during stretch installation

[Roberto C . Sánchez]

On Tue, Jul 31, 2018 at 06:05:04PM -0700, David Christensen wrote:
> On 07/31/2018 05:42 PM, Roberto C. Sánchez wrote:
> > On Tue, Jul 31, 2018 at 05:36:41PM -0700, David Christensen wrote:
> > > 
> > > One possibility is to  configure your Internet gateway to block traffic
> > > between the host and the Internet, and then install from CD-1, DVD-*, 
> > > BD-*,
> > > etc., media.
> > > 
> > An easier approach would be that when the installer asks "Would you like
> > to use a network mirror?" you just answer "no."  The installer will then
> > only use the packages available on the install media you supply.
> 
> The first half of my suggestion implies your suggestion.
> 
> 
> The original post implies use of netinst media, which does not contain
> enough packages to install a working Debian system (?).  Thus, the second
> half of my suggestion.
> 
I should have read the entire thread before responding.  Thanks for
pointing out my oversight.

You are correct that a netinst media does not have enough on it for a
complete installation.  However, that is sort of the point of the
netinst media.  Of course, another aspect of the way updates work in
Debian is that when a point update is made all the security updates (and
generally quite a few high priority non-security updates) become part of
the stable release with an increased version number.  For example in the
last few weeks, Debian "Stretch" went from version 9.4 to 9.5.

That sort of makes the "I want to install but I don't want security
updates" not make any sense.  Unless you get the install media for the
first release of a new Stable before any point releases are made, you
will end up with some security updates as part of your installation.
Even then, the new stable release definitely also has security updates
that are left over from the prior stable release (not all packages are
refreshed from one release to the next).

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: how to prevent security update installation during stretch installation

[David Christensen]

On 07/31/2018 05:42 PM, Roberto C. Sánchez wrote:

On Tue, Jul 31, 2018 at 05:36:41PM -0700, David Christensen wrote:


One possibility is to  configure your Internet gateway to block traffic
between the host and the Internet, and then install from CD-1, DVD-*, BD-*,
etc., media.


An easier approach would be that when the installer asks "Would you like
to use a network mirror?" you just answer "no."  The installer will then
only use the packages available on the install media you supply.


The first half of my suggestion implies your suggestion.


The original post implies use of netinst media, which does not contain 
enough packages to install a working Debian system (?).  Thus, the 
second half of my suggestion.



David

Re: how to prevent security update installation during stretch installation

[Roberto C . Sánchez]

On Tue, Jul 31, 2018 at 05:36:41PM -0700, David Christensen wrote:
> 
> One possibility is to  configure your Internet gateway to block traffic
> between the host and the Internet, and then install from CD-1, DVD-*, BD-*,
> etc., media.
> 
An easier approach would be that when the installer asks "Would you like
to use a network mirror?" you just answer "no."  The installer will then
only use the packages available on the install media you supply.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: how to prevent security update installation during stretch installation

[David Christensen]

On 07/31/2018 02:56 PM, Long Wind wrote:

i plan to install debian by network


Okay.


i don't like security update, 


Why not?



how to do it? Thanks!


One possibility is to  configure your Internet gateway to block traffic 
between the host and the Internet, and then install from CD-1, DVD-*, 
BD-*, etc., media.



David

Re: Logs flooded with the same message

[Thiago Machado da Silva]

I've solved this problem creating a xorg.conf file at /etc/X11/ with
the command "Xorg -configure" and disabling PageFlip in this file at
the section Device, uncommenting the Option "PageFlip" and setting it
to "False" (between quotes).

--
Thiago Machado da Silva

Re: update hell

[Default User]

I was going to read up on:

apt-get dist-upgrade -V -s

But then today, I was able to do a full upgrade, using:

sudo aptitude -Pvv update
sudo aptitude -Pvv safe-upgrade
sudo aptitude -Pvv full-upgrade

Finally!

Now, I'm sure using:

apt-get dist-upgrade -V -s

would have worked as well, although I thought I read somewhere that mixing
apt-get and aptitude is not a good idea.

Thanks again, Ben.

And, btw . . .

dpkg?
apt-get?
aptitude?
apt?

Would Debian please just settle on one, and stick with it?





On Jul 30, 2018 8:17 PM, "Ben Caradoc-Davies"  wrote:

On 31/07/18 12:08, Default User wrote:
> As for me, I think I will just wait until the "transition" is over (or at
> least this part of it) before upgrading packages with dependency issues.
> When in doubt, do nothing.

When I am in doubt, I simulate a dist-upgrade with:

apt-get dist-upgrade -V -s


Kind regards,

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: a dh keys question?

[Karen Lewellen]

Hi
just putting my answer at the top.
My client does have a log option, will aim for that.  still again my first 
priority is finding a place to test  with a nonstandard port.  then I can 
be sure  it really is all about port 22 and 21.

Kare



On Tue, 31 Jul 2018, Dan Ritter wrote:


On Tue, Jul 31, 2018 at 01:01:31PM -0400, Karen Lewellen wrote:

Hi again,



ssh-keygen is a command that comes along with your SSH client in
Debian (and all other UNIX-like systems that supply OpenSSH).

Understood.


That sounds like your DSL company decided to block port 22,
which is somewhere between ridiculous and evil.

(21 is FTP, by the way.)

Yes, on port 21 being for ftp, meaning it would have to be blocked as well
which   seems frankly impossible.




1. Reboot your DSL modem and/or router just in case.

Not only has that been done, I actually  got someone at Bell Canada to reset
my account information on their side to default.
That worked once before when I could not reach dreamhost.

2. Test that you still can't ssh to server:22
3. Test that you can't connect via ssh to chat.shazow.net (it
will allow anyone on, no credentials)


Okay, did that once producing the same dh key error, but will do it again
with /v to note what happens.


4. Complain to your DSL company.


But that is why I desire a server to test that, like here at shellworld, is
using something other than port 22.  Otherwise I just get a repeat of the
same conversation, we do not support your operating system.
Although, I am wondering, if the port were blocked, if  I would get as much
information as I am getting from /v?


Show us the whole output.

-dsr-

Re: What's the deal with the mpfr versioning? libmpfr4 vs. libmpfr6

[Stefan Monnier]

> I can't find any evidence for that without being told where to look.

It was in the previous message:

https://packages.debian.org/sid/libmpfr4
https://packages.debian.org/sid/libmpfr6

>> Doesn't explain why one says "Package: libmpfr4 (3.1.6-1)" and the other
>> says "[mpfr4_4.0.1-1.dsc]": both "3.1.6-1" and "4.0.1-1" are Debian
>> version numbers and they are usually the same.
>
> I'm not sure you're quoting from here.

>From https://packages.debian.org/sid/libmpfr4

> That seems unlikely to me. I'm not going to bother to download the
> source to find out, but I suspect that the 4 in Packages's "Source:
> mpfr4" line is spurious,

Agreed, I hadn't noticed this little "4" in there.  I have no idea what
it means.  I was only looking at (and talking about) the Debian
version numbers and the "4" and "6" of "libmpfr4" and "libmpfr6".


Stefan

Re: a dh keys question?

[Dan Ritter]

On Tue, Jul 31, 2018 at 01:01:31PM -0400, Karen Lewellen wrote:
> Hi again,
> 
> 
> > ssh-keygen is a command that comes along with your SSH client in
> > Debian (and all other UNIX-like systems that supply OpenSSH).
> Understood.
> 
> > That sounds like your DSL company decided to block port 22,
> > which is somewhere between ridiculous and evil.
> > 
> > (21 is FTP, by the way.)
> Yes, on port 21 being for ftp, meaning it would have to be blocked as well
> which   seems frankly impossible.
> 
> 
> > 
> > 1. Reboot your DSL modem and/or router just in case.
> Not only has that been done, I actually  got someone at Bell Canada to reset
> my account information on their side to default.
> That worked once before when I could not reach dreamhost.
> > 2. Test that you still can't ssh to server:22
> > 3. Test that you can't connect via ssh to chat.shazow.net (it
> > will allow anyone on, no credentials)
> 
> Okay, did that once producing the same dh key error, but will do it again
> with /v to note what happens.
> 
> > 4. Complain to your DSL company.
> 
> But that is why I desire a server to test that, like here at shellworld, is
> using something other than port 22.  Otherwise I just get a repeat of the
> same conversation, we do not support your operating system.
> Although, I am wondering, if the port were blocked, if  I would get as much
> information as I am getting from /v?

Show us the whole output.

-dsr-

Logs flooded with the same message

[Thiago Machado da Silva]

Hello,

The files .local/share/xorg/Xorg.0.log, /var/log/user.log and
/var/log/syslog are flooded with the same messages. The files are
huge. The messages are:

(EE) modeset(0): Failed to get GBM bo for flip to new front.
(EE) modeset(0): present flip failed



--
Thiago Machado da Silva

Re: a dh keys question?

[Karen Lewellen]

Hi again,



ssh-keygen is a command that comes along with your SSH client in
Debian (and all other UNIX-like systems that supply OpenSSH).

Understood.


That sounds like your DSL company decided to block port 22,
which is somewhere between ridiculous and evil.

(21 is FTP, by the way.)
Yes, on port 21 being for ftp, meaning it would have to be blocked as well 
which   seems frankly impossible.





1. Reboot your DSL modem and/or router just in case.
Not only has that been done, I actually  got someone at Bell Canada to 
reset my account information on their side to default.

That worked once before when I could not reach dreamhost.

2. Test that you still can't ssh to server:22
3. Test that you can't connect via ssh to chat.shazow.net (it
will allow anyone on, no credentials)


Okay, did that once producing the same dh key error, but will do it again 
with /v to note what happens.



4. Complain to your DSL company.


But that is why I desire a server to test that, like here at shellworld, 
is using something other than port 22.  Otherwise I just get a repeat of 
the same conversation, we do not support your operating system.
Although, I am wondering, if the port were blocked, if  I would get as much 
information as I am getting from /v?

Kare

Re: a dh keys question?

[Dan Ritter]

On Tue, Jul 31, 2018 at 12:07:53PM -0400, Karen Lewellen wrote:
> 
> Hi, thanks  with answers.
> 
> On Tue, 31 Jul 2018, Dan Ritter wrote:
> 
> > 
> > You generate a private/public key pair with ssh-keygen, and send
> > the public key over to your destination in advance, so that they
> > can recognize you.
> 
> Okay, I understand.  Meaning that keygen is a part of the ssh client I take
> it?

ssh-keygen is a command that comes along with your SSH client in
Debian (and all other UNIX-like systems that supply OpenSSH).


> > Are you having problems SSHing to all servers that you try, or
> > just to one in particular?
> 
> I am having problems with every server I try, aside from  the one using the
> different port from 21 & 22.
> So, it is the reverse of what you suggest.  I wish I could test another
> server using an alternative port to see  if that works.

That sounds like your DSL company decided to block port 22,
which is somewhere between ridiculous and evil.

(21 is FTP, by the way.)

1. Reboot your DSL modem and/or router just in case.

2. Test that you still can't ssh to server:22

3. Test that you can't connect via ssh to chat.shazow.net (it
will allow anyone on, no credentials)

4. Complain to your DSL company.

-dsr-

Re: What's the deal with the mpfr versioning? libmpfr4 vs. libmpfr6

[David Wright]

On Tue 31 Jul 2018 at 10:01:00 (-0400), Stefan Monnier wrote:
> >> Funny thing is, this is what the versioning says on those pages:
> >> Package: libmpfr4 (3.1.6-1)
> >> Package: libmpfr6 (4.0.1-1)
> >>
> >> ...ok, that's strange. Even weirder, they are both built from the same
> >> sources: mpfr-4.0.1-1.
> 
> Indeed, I find that odd.

I can't find any evidence for that without being told where to look.

> I suspect that the "3.1.6-1" in the "title" and the "4.0.1-1" in the
> "download from source" refer to different versions of the package
> (normally, those two are identical).
> 
> Not sure how/why this happens.  Maybe the source package has been
> upgraded, but the build of the corresponding binaries is still
> in-progress?
> 
> >> I feel like I'm missing something. For example, what does the
> >> "3.1.6-1" mean in libmpfr4?
> 
> Usually it means "built from the upstream version 3.1.6 with some local
> patches" and the "-1" is a Debian-local sub-version, in case Debian
> builds several different versions of the package from the same upstream
> versions (e.g. because Debian's own patches are modified, a typical
> example being when Debian's security team backports a security patch to
> 3.1.6).

Usually they are, but you can't always rely on it; eg Grub2 had
Debian version numbers 1.x in the days of wheezy. You have to check a
little deeper: that was my point.

> > The numbers in parentheses are the Debian versions of the package.
> > That's how apt would upgrade a package if a bug was fixed within it.
> > They're not related to the upstream version.
> 
> Doesn't explain why one says "Package: libmpfr4 (3.1.6-1)" and the other
> says "[mpfr4_4.0.1-1.dsc]": both "3.1.6-1" and "4.0.1-1" are Debian
> version numbers and they are usually the same.

I'm not sure you're quoting from here.

> > As for the "6", I'm guessing that they chose that because the library
> > version (yes, another versioning sequence) is 6.0.1 as opposed to 4.1.5.
> 
> That's right, this is an "API version", so I guess it means that the
> 4.0.1 upstream code can be used to build both the API version 4 and
> the API version 6.

That seems unlikely to me. I'm not going to bother to download the
source to find out, but I suspect that the 4 in Packages's "Source:
mpfr4" line is spurious, accidentally introduced between lenny and
squeeze. I think that is the only mystery here, and the rest of the
"problem" is built on jumping to false conclusions (or assumptions).

Cheers,
David.

Re: a dh keys question?

[Karen Lewellen]

Hi, thanks  with answers.

On Tue, 31 Jul 2018, Dan Ritter wrote:



You generate a private/public key pair with ssh-keygen, and send
the public key over to your destination in advance, so that they
can recognize you.


Okay, I understand.  Meaning that keygen is a part of the ssh client I 
take it?



Are you having problems SSHing to all servers that you try, or
just to one in particular?


I am having problems with every server I try, aside from  the one using 
the  different port from 21 & 22.
So, it is the reverse of what you suggest.  I wish I could test another 
server using an alternative port to see  if that works.





Thanks,
Karen

Re: a dh keys question?

[Dan Ritter]

On Tue, Jul 31, 2018 at 11:38:34AM -0400, Karen Lewellen wrote:
> Hi everyone,
> While the question seems simple, at least to me, the reason behind it is
> complicated.  so I am hoping to focus on the question first.
> During the dh key exchange process, where do the user dh key packets come
> from software wise?

You generate a private/public key pair with ssh-keygen, and send
the public key over to your destination in advance, so that they
can recognize you.

> I have a problem now where each place I try to visit using my ssh client,
> and my sftp one, I am getting a dh key exchange failure.
> using the -v command  is not shedding light on the issue.
> I am using the same client now to reach another  service, but here  we use a
> different port from port 22.
> the error started on the 29th of June, and the company providing my dsl
> service did claim to have a service issue on that day.
> However they do not speak Linux let alone anything else Unusual.
> Thoughts?


Are you having problems SSHing to all servers that you try, or
just to one in particular?

If it's just one, and that one uses a port other than 22, it's
likely that your DSL company started filtering that port on the
29th. 

-dsr-

a dh keys question?

[Karen Lewellen]

Hi everyone,
While the question seems simple, at least to me, the reason behind it is 
complicated.  so I am hoping to focus on the question first.
During the dh key exchange process, where do the user dh key packets come 
from software wise?
I have a problem now where each place I try to visit using my ssh client, 
and my sftp one, I am getting a dh key exchange failure.

using the -v command  is not shedding light on the issue.
I am using the same client now to reach another  service, but here  we use 
a different port from port 22.
the error started on the 29th of June, and the company providing my dsl 
service did claim to have a service issue on that day.

However they do not speak Linux let alone anything else Unusual.
Thoughts?

Re: What's the deal with the mpfr versioning? libmpfr4 vs. libmpfr6

[Stefan Monnier]

>> Funny thing is, this is what the versioning says on those pages:
>> Package: libmpfr4 (3.1.6-1)
>> Package: libmpfr6 (4.0.1-1)
>>
>> ...ok, that's strange. Even weirder, they are both built from the same
>> sources: mpfr-4.0.1-1.

Indeed, I find that odd.

I suspect that the "3.1.6-1" in the "title" and the "4.0.1-1" in the
"download from source" refer to different versions of the package
(normally, those two are identical).

Not sure how/why this happens.  Maybe the source package has been
upgraded, but the build of the corresponding binaries is still
in-progress?

>> I feel like I'm missing something. For example, what does the
>> "3.1.6-1" mean in libmpfr4?

Usually it means "built from the upstream version 3.1.6 with some local
patches" and the "-1" is a Debian-local sub-version, in case Debian
builds several different versions of the package from the same upstream
versions (e.g. because Debian's own patches are modified, a typical
example being when Debian's security team backports a security patch to
3.1.6).

> The numbers in parentheses are the Debian versions of the package.
> That's how apt would upgrade a package if a bug was fixed within it.
> They're not related to the upstream version.

Doesn't explain why one says "Package: libmpfr4 (3.1.6-1)" and the other
says "[mpfr4_4.0.1-1.dsc]": both "3.1.6-1" and "4.0.1-1" are Debian
version numbers and they are usually the same.

> As for the "6", I'm guessing that they chose that because the library
> version (yes, another versioning sequence) is 6.0.1 as opposed to 4.1.5.

That's right, this is an "API version", so I guess it means that the
4.0.1 upstream code can be used to build both the API version 4 and
the API version 6.


Stefan

Re: Set the MTU on the interface

[Michael Stone]

On Mon, Jul 30, 2018 at 03:55:52PM +0300, Алексей wrote:

I can't set the MTU in the eth0 configuration. I can probably write a pre-up
directive in the configuraion of the first vlan interface however I'm not sure
if this is correct way. Probably someone can advice better one?


You can do it with a pre-up to set the mtu of the base device. Once you 
set the base device to 9000 or whatever, you'll want to set the mtu on 
all of the other devices to the original value.


Mike Stone

Re[2]: Set the MTU on the interface

[Алексей]

Hi.

Here it is:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
#auto eth1
#auto eth2
auto eth3

auto vlan8
iface vlan8 inet static
address 10.255.8.1
netmask 255.255.255.252
vlan-raw-device eth0

auto vlan5
iface vlan5 inet static
address 10.255.5.1
netmask 255.255.255.0
vlan-raw-device eth0

auto vlan4
iface vlan4 inet static
address 10.255.4.1
netmask 255.255.255.0
vlan-raw-device eth3
###


30 июля 2018, 17:14:10, от "Dan Ritter" :

On Mon, Jul 30, 2018 at 03:55:52PM +0300, Алексей wrote:
> Hi!
> 
> I need an advice about how can I set the MTU on the interface which is not in 
> fact configured. So to explain in more detail:
> 
> I have a debian box acting as a router and it has interface let's say eth0. 
> Eth0 itself doesn't have any IP configuration, all IP configuration and 
> routing is done on vlan interfaces bound to eth0. I need to route jumbo 
> frames so I need to set the MTU on vlan interfaces to 9000 and consequently I 
> need to set MTU to 9000 on the physical eth0 also. However, as i have only 
> one line for eth0 in /etc/network/interfaces:
> 
> auto eth0
> 
> I can't set the MTU in the eth0 configuration. I can probably write a pre-up 
> directive in the configuraion of the first vlan interface however I'm not 
> sure if this is correct way. Probably someone can advice better one?
> 

Please show us your entire /etc/network/interfaces.

-dsr-

Re: Question about /proc/loadavg

[Martin Drescher]

[...]
> Hi Martin,
> 
> can you show real data from /proc/loadavg output? Which column do you
> compare?

I' talking about the 1/5/15 minute numbers.

> I wouldn't worry about difference in /proc/loadavg because everything is
> different between RHEL/CentOS 6 and Debian 9 - kernel, Apache version,
> different patches, etc. For example if I/O is faster on Debian 9 then
> it's normal to have higher CPU load on the server, if I understood you
> correctly.

I'm aware there are differences. But both Apache HTTP versions (2.2 and 2.4, 
both in prefork mode) are running at an almost identical configuration, same 
content, same (virtual) hardware. In top(1) I can see, user, system, idle and 
wait are quite equal to each other. What I'm curious about is, how can this 
loadavg numbers then be _that_ different.

> Kind regards
> Georgi

Thanks, Martin




signature.asc
Description: OpenPGP digital signature

Re: Question about /proc/loadavg

[Georgi Naplatanov]

On 07/31/2018 10:31 AM, Martin Drescher wrote:
> Hi ML members,
> 
> I have a question about how the numbers compute which I get from 
> /proc/loadavg.
> I'm running a bunch of HTTP servers, most of them running a RHEL 6, which is 
> a kernel version 2.6. All patches applied, so that Meltdown and Spectre stuff 
> should be included. Some of the servers where migrated to a Debian 9 with a 
> kernel version 4.9, also all patches applied. What I see is a tremendous 
> difference in /proc/loadavg. It is like 3 ~ 4 in kernel 2.6 and like 15 ~ 20 
> in 4.9. It is not a real problem, that Debian is running well.
> But does someone has a clue, what makes that difference?

Hi Martin,

can you show real data from /proc/loadavg output? Which column do you
compare?

I wouldn't worry about difference in /proc/loadavg because everything is
different between RHEL/CentOS 6 and Debian 9 - kernel, Apache version,
different patches, etc. For example if I/O is faster on Debian 9 then
it's normal to have higher CPU load on the server, if I understood you
correctly.

Kind regards
Georgi

Question about /proc/loadavg

[Martin Drescher]

Hi ML members,

I have a question about how the numbers compute which I get from /proc/loadavg.
I'm running a bunch of HTTP servers, most of them running a RHEL 6, which is a 
kernel version 2.6. All patches applied, so that Meltdown and Spectre stuff 
should be included. Some of the servers where migrated to a Debian 9 with a 
kernel version 4.9, also all patches applied. What I see is a tremendous 
difference in /proc/loadavg. It is like 3 ~ 4 in kernel 2.6 and like 15 ~ 20 in 
4.9. It is not a real problem, that Debian is running well.
But does someone has a clue, what makes that difference?



signature.asc
Description: OpenPGP digital signature