Re: [CentOS] A repo with latest httpd for http2?

[Guolin Cheng]

How about here, if you are using centos 6.

http://mirror.centos.org/centos/6/SCL/x86_64/httpd24/

On Fri, Feb 12, 2016 at 2:23 PM, Ulf Volmer  wrote:

> On 02/12/2016 10:54 PM, John R Pierce wrote:
>
>> On 2/12/2016 11:13 AM, SternData wrote:
>>
>>> Is there a well-run package repo that has httpd-2.4.17 or mod_http2 (or
>>> mod_h2)?
>>>
>>
>> EL7 comes with httpd-2.4...
>>
>> # yum list httpd
>> ...
>> Installed Packages
>> httpd.x86_64 2.4.6-40.el7.centos @base
>>
>
> Including support for http2?
>
> i doubt that. As far as i know, support was added with 2.4.17.
>
> [root@centos7 ~]# rpm -ql httpd|egrep 'mod_http2|mod_h2'
> [root@centos7 ~]#
>
> best regards
> Ulf
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



-- 
Best,
Guolin
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SSHD rootkit in the wild/compromise for CentOS 5/6?

[Guolin Cheng]

It makes some sense to follow RHEL's suit, but Gelen's suggestions gain more 
points here too.

As end users we probably turn off the default prelink settings after 
RHEL/Centos initial installation, it is not a rocket technology.


On 2/26/13 8:10 AM, Johnny Hughes joh...@centos.org wrote:

On 02/25/2013 04:24 PM, Gelen James wrote:
 'rpm -V' can be misleading, if taking into account of prelink on 
 Redhat/Centos Boxes which is running through cron by default. I've shown the 
 steps on reverse the effect of prelink at the comments sections at link 
 https://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229?storyid=15229. I'm 
 afraid that 'rpm -V' only will make big noises or false alarms.

 But in general, maybe it is a good time to turn off prelink, or more 
 aggressively, remove prelink packages from Centos 5/6? the prelink is said to 
 bring some performance boost, but who really cares in the era of tens of 
 CPUs? nowadays and later on we are -- and will -- more concerned on security 
 threats instead of 3~5 percents CPU/performance gain, right?

RHEL does prelinking by default, we therefore will never turn it off in
CentOS by default.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

a quick and dirty hack to 'fix' the problem in a large scale -- RE: [CentOS] Nic order detection

[Guolin Cheng]

Les and Michael,

There are a few ways to workaround the NIC detection issue. Each has its
own advantages and limits.

The first method is: suppose you or your team have full control of
running kernel on your hundreds/thousands of boxes, your can then build
some NIC drivers statically in the kernel -- these statically built NIC
drivers will be detected as eth0 without glitches -- then leave other
different NIC types on the same box still in dynamic kernel modules
status. It works greatly if you know all the types of primary network
NIC. Typically e100, tg3, etc. and you have already standardized the 2nd
NIC on the boxes to one or two brands like e1000.

The second method is: suppose you or your team can not control
rebuilding of kernel, or at least you have no full control, but you
really know the types of primary/secondary NICs combinations on all the
Linux boxes in your kingdom. Then you can try the following hack:

 You can try to add/change lines in /lib/modules/`uname -r`/modules.dep
file according to your NICs combinations -- always load the drivers
according to your predefined order. For example:

.../e1000.ko: .../tg3.ko .../3c59x.ko .../e100.ko .../forcedeth.ko
.../forcedeth.ko: .../tg3.ko

The above means to load the module at left, system will first load
modules at right! So tg3|3c59x|e100|forcedeth always load before e1000,
and tg3 load before forcedeth. The same idea can be applied to all NIC
combination types your have and can be set only once and applied to all
your linux boxes if you set it up correctly. The side-effect is: you
have waste few hundreds Kilobytes memory, but who cares?

There are also other tricks I tried before, some works and some not. But
I think the above should probably work for most general cases.

Have a good weekend.

--Guolin


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Michael D. Kralka
Sent: Thursday, January 10, 2008 6:52 AM
To: CentOS mailing list
Subject: Re: [CentOS] Nic order detection

Les Mikesell wrote:
 I do have the ifcfg-ethX files for the 2 interfaces that are currently
 active, but since the machines were built by image copies of a master
 disk, they do not have HWADDR address entries.  A person on-site with
 access to the console adjusted them if they didn't come up right the
 first time, but they seem to shift around on each reboot.  Will adding
 the HWADDR entry nail them down even if it doesn't match the nic type
 specified in modprobe.conf?  Can someone point me to the code where
this
 happens?  Until recently the machines were running centos 3.x and this
 seems to be a difference in behavior.

As already pointed out, yes adding HWADDR will nail them down and the
entries in modprobe.conf don't mean much. If you (or a script) execute
modprobe eth0 it will load the appropriate module. Unfortunately, this
is not how CentOS 5 loads drivers.

With CentOS 5, udev is used to load the drivers by looking at the
modalias file found for each device under the /sys directory (search
for them, there are many). For PCI devices, the modalias includes the 4
16-bit PCI ID values, the PCI device type, and some other information.

Unfortunately, udev tries to be clever and loads drivers in parallel. As
a result, if there are NICs that use different drivers, the order that
the NICs are assigned ethX interfaces is left to the whim of the Linux
scheduler (i.e. is non-deterministic). Devices using the same driver
will always be assigned interface names in the same relative ordering.
If they all use the same driver, they will always be assigned the same
names, without having to fuss with the HWADDR option (this is due to how
drivers enumerate PCI devices).

In reality, HWADDR doesn't force the kernel to assign the desired
interface to each device. It simply cleans up after udev by renaming
the interfaces from what the kernel assigned to each NIC to the
interfaces you expect. Search for rename_device in ifup-eth and
network-functions, both found in the /etc/sysconfig/network-scripts
directory.

Cheers,
Michael
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

RE: a quick and dirty hack to 'fix' the problem in a large scale-- RE: [CentOS] Nic order detection

[Guolin Cheng]

Michael,

 There are no points to argue about which are the best 'official' ways
which just like a war between vi or Emacs before. I may be stupid but
any methods fix users' problem are the best ones. I've tried the
official 'rename' or udev ways before, but finally I gave up and end up
the two ways I've mentioned. Espectially the seconds, it works perfectly
when I rerolled my Centos 5.0 and 5.1 initrd.img files for custom
Kickstart installation in a really large scale.

Good luck and have a new year.

--Guolin




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Michael D. Kralka
Sent: Saturday, January 12, 2008 5:41 AM
To: CentOS mailing list
Subject: Re: a quick and dirty hack to 'fix' the problem in a large
scale-- RE: [CentOS] Nic order detection

Guolin Cheng wrote:
 Les and Michael,

I am going to bite my tongue and not ask to you refrain from top
posting.

As your subject suggests, you are proposing a quick and dirty hack to
deal with interface assignment to physical NICs. Why bother with a quick
and dirty hack when a sensible solution exists within the distribution?
I see this a bad advice and hope no one follows it.

 There are a few ways to workaround the NIC detection issue. Each has
its
 own advantages and limits.
 
 The first method is: suppose you or your team have full control of
 running kernel on your hundreds/thousands of boxes, your can then
build
 some NIC drivers statically in the kernel -- these statically built
NIC
 drivers will be detected as eth0 without glitches -- then leave other
 different NIC types on the same box still in dynamic kernel modules
 status. It works greatly if you know all the types of primary network
 NIC. Typically e100, tg3, etc. and you have already standardized the
2nd
 NIC on the boxes to one or two brands like e1000.

Although this may work, I have just signed up for a lifetime of
chasing kernel versions. Every time RHEL/CentOS release a new kernel to
fix a bug or security vulnerability, I must recompile the kernel. How
does this make sense if I have hundreds/thousands of boxes to to keep up
to date? I'd rather yum update on all the boxes (which is easy to do)

 The second method is: suppose you or your team can not control
 rebuilding of kernel, or at least you have no full control, but you
 really know the types of primary/secondary NICs combinations on all
the
 Linux boxes in your kingdom. Then you can try the following hack:
 
  You can try to add/change lines in /lib/modules/`uname
-r`/modules.dep
 file according to your NICs combinations -- always load the drivers
 according to your predefined order. For example:
 
 .../e1000.ko: .../tg3.ko .../3c59x.ko .../e100.ko .../forcedeth.ko
 .../forcedeth.ko: .../tg3.ko

Although this may work, it is another accident waiting to happen. This
is a generated file and it is almost never a good idea to modify an
generated file; one will get burned. I install a shiny new module that
is not delivered as part of the kernel (drbd perhaps), and the
post-install script runs depmod -a (a sensible thing to do); now I
have just blown away the manual changes. Or ever time I install a new
kernel (whether I am foolishly[1] building my own or using the
distribution kernels), I have to remember to make this change. The worst
part about this is that the effects will not be visible until the next
time the server is rebooted (say 6 months when there is a power
failure); the network interface assignment will be wrong. Good luck
hunting down that problem in a pinch!

[1]  Don't get me wrong, there is a time and a place for building custom
kernels; this is just not one of them.

 The above means to load the module at left, system will first load
 modules at right! So tg3|3c59x|e100|forcedeth always load before
e1000,
 and tg3 load before forcedeth. The same idea can be applied to all NIC
 combination types your have and can be set only once and applied to
all
 your linux boxes if you set it up correctly. The side-effect is: you
 have waste few hundreds Kilobytes memory, but who cares?

The problem is not the wasted memory, it's the fragility of its design.

 There are also other tricks I tried before, some works and some not.
But
 I think the above should probably work for most general cases.

Why resort to tricks when there is a perfectly good solution supported
by the distribution? I've learned that it never pays to be clever. When
resorting to neat little tricks to get things to work, they get
forgotten, or worse when someone else must look into a problem, they
spend most of the time trying to understand the clever way things are
set up. When stability is a main concern, boring is always better.

Cheers,
Michael

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

RE: [CentOS] Nic order detection

[Guolin Cheng]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of MatsK
Sent: Thursday, January 10, 2008 12:42 PM
To: CentOS mailing list
Subject: Re: [CentOS] Nic order detection

Les Mikesell wrote:
 Can someone point me to the code where this 
 happens?  Until recently the machines were running centos 3.x and this

 seems to be a difference in behavior.

CentOS 3 and 4 uses dev structure but with 5 was udev introduced. Thats 
the reason for the changes, but if you uses the 
/etc/sysconfig/network-scripts will everything be fine. Read more about 
it in the RHEL manual.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Thanks -- RE: [CentOS] kickstart fails statically built custom kernel: anacondadoesn't honor static NIC/SATA driver in kernel?

[Guolin Cheng]

Mogens,

 The Booting Sequence problem is described below:

 Two types of NICs are installed on one machine, BIOS/PXE boots from one
type, but after that Linux/Kickstart kernel detect another type NIC as
eth0 and trying to install from that unconnected NIC.

 A custom kernel is built to statically built-in the BIOS/PXE detected
NIC's driver into kernel, hoping to fix the problem in a hard way but
failed.

Kickstart/anaconda always try to load a .ko driver for each detected NIC
types, so when the driver is static built (into kernel), the Kickstart
process hangs because it can not locate/load the related .ko module
file.

I have fixed the problem in a non-standard way, not very elegant but
works. 

By the way, the suggested 'noprob,nonet' and 'device eth0
module1:module2:...' combination doesn't work at all for my case --
since the latter is defined in a ks.cfg but my ks.cfg needs to be
downloaded from network.

--Guolin




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Mogens Kjaer
Sent: Saturday, June 09, 2007 5:49 AM
To: CentOS mailing list
Subject: Re: [CentOS] kickstart fails statically built custom kernel:
anacondadoesn't honor static NIC/SATA driver in kernel?

Guolin Cheng wrote:
...
 The network card driver tg3 is statically built into custom kernel to
 fix NIC driver loading sequence problem( I have mixed type NICs on
 these boxes), so there is no tg3.ko in my rolled modules/modules.cgz
 file.

Could you explain loading sequence problem?

Mogens

-- 
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: [EMAIL PROTECTED] Homepage: http://www.crc.dk
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos