I have a Cisco 6509 switch that I'm monitoring with SNMP from a
CentOS5 machine. SNMP polls are the only access I have to this
device, we are not allowed to log on via telnet.
How can I find out which port on the switch a particular server is
connected to? I was hoping that this is somehow possible using the
mac address and the data gathered from snmpwalk/snmpget requests but
I'm not having much luck. How would you tackle this problem?
HI ALL,
Ive recently installed Cent OS 5.2 , and now want to update a few more
packages , how can i do that with the installation CDs.
pls help..
cheers,
Sumit
Anthony Kamau wrote:
> > -----Original Message-----
> > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org]
> > On Behalf Of Bowie Bailey Sent: Saturday, 25 April 2009 6:27 AM
> > To: CentOS mailing list (E-mail)
> > Subject: [CentOS] repository for mod_security
> >
> > I want to add mod_security to my Apache server running CentOS 5.3
> > and am trying to find a repository to get it from. I found it in
> > EPEL, but they have version 2.1.7, which is over a year old
> > according to what I found on the modsecurity.org website. Is there
> > a repository which is keeping this up to date? Or should I just
> > build it from source?
>
> Interesting that you are finding version 2.1.7 - just did a quick
> check and I see version 2.5.9 on epel:
>
> Name : mod_security
> Arch : i386
> Version : 2.5.9
> Release : 1.el5
> Size : 933 k
> Repo : epel
That is very strange. I checked this morning and I see 2.5.9 in epel,
but I'll swear that I saw 2.1.7 on Friday. I didn't change anything, I
just did another "yum info mod_security". I guess I'll use epel.
Thanks,
--
Bowie
Hi all
I am using cents 5.3 on a gigabyte motherboard MA78GM-US2H.
When installing centos using kickstart I get prompted to load a driver.
I select the ata_piix driver
and everything continues as normal.
Is there a way in kickstart or the boot command prompt line to specify
loading the ata_piix module automatically?
Why isnt the kernel loading it automatically? I dont recall having to
ever do that before in 5.2
Thanks,
Jerry
-----Original Message-----
From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On
Behalf Of Barry Brimer
Sent: Friday, April 24, 2009 5:44 PM
To: CentOS mailing list
Subject: Re: [CentOS] Certificate system
Quoting J.Witvliet(a)MINDEF.NL:
> Hi all,
>
> Can anybody inform me wether the "RedHat Certificate System" or
> actually a CentOS equivalent is available for CentOS.
> Just skimmed on a download site through the RPM's for 5.3 and I
> couldn't find it.
> According to their pressrelease, it the code should be gpl, allthough
> I can't find any rpm for RH, FC or Centos.
>
> It seems that this is one of the few CA-packages for large scale
> deployment of certificates.
> Only alternative AFAIK is OpenCA, which seems to be hardly
maintained...
> ( binaries on their site are old, and source code yields lots of
> errors during build..)
The Fedora version of RHCS is called Dogtag
<http://pki.fedoraproject.org/wiki/PKI_Main_Page>
You might have to modify/rebuild their SRPMS.
Yes, i came across dogtag.
However i got the impression it was something in the same category like
tinyca or pyca.
Perhaps it is based on the code of RHCS, and all documentation is just
some wiki pages.
Bit different from the docu from RHCS-7.3 (Their admin guide is over 600
pages)
I was asked to make a proposal for an (large) opensource CA/RA/ocsp/....
If selected, i make them order an official package with support from RH.
But i would like to have some hands-on experience before, and not get
all my information from paper.
OpenCA has also quite some nice docu (but doesn't live up to it), and
used to be included in some distro's.
So, ejbca seems to be more appropiate than dogtag (if i can't get RHCS)
hw
______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
I have a strange problem on one machine where eth0 gets killed when I add
a virtual interface. It's got something to do with the NIC ordering or
with the xen network script having a problem with multiple NICs and
virtual interfaces. I could need some help/comments on this.
Some history:
I added a NIC (chip identifies as Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet) to a Dell R200 server.
CentOS 5.3 with Xen 3.3.1 (gitco repo). eth0 and eth1 are the built-in
NICs, this is then eth2 (or it should be).
Works. Everything is fine until I add a virtual interface to eth0 and
reboot. I can add eth0:1 at runtime just fine. But if I let it stay in
network-scripts and boot the whole eth0 is killed (doesn't show up in
ifconfig and doesn't work). A network restart brings it up as if nothing
is wrong.
I first thought it might have something to do with the fact that eth0 is
actually a bridge on Xen > 3.2 and tried the same config on another
machine and there it works. It's not the exact same xen version, not 64bit
and it's got only 1 NIC. So there are differences, but it seems to rule
out the bridge as a cause.
I then checked the logs more thoroughly and found that CentOS changes the
NIC initialization order at boot-time.
Without the third NIC it's eth0=NIC1 and eth1=NIC2 (as shown on the
chassis). But with the third NIC it's most often that one that goes first.
Here's a typical excerpt from messages. tigon/tg3 is the driver for the
internal NICs which normally were on eth0 and eth1.
Apr 25 19:00:59 c4 kernel: eth0: RTL8168b/8111b at 0xffffc20000022000,
00:21:27:c9:d1:f5, XID 38000000 IRQ 16
Apr 25 19:00:59 c4 kernel: eth1: Tigon3 [partno(BCM95721) rev 4201 PHY
(5750)] (PCI Express) 10/100/1000Base-T Ethernet 00:1e:c9:fe:fb:ab
Apr 25 19:00:59 c4 kernel: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1]
WireSpeed[1] TSOcap[1]
Apr 25 19:00:59 c4 kernel: eth1: dma_rwctrl[76180000] dma_mask[64-bit]
Apr 25 19:00:59 c4 kernel: eth2: Tigon3 [partno(BCM95721) rev 4201 PHY
(5750)] (PCI Express) 10/100/1000Base-T Ethernet 00:1e:c9:fe:fb:ac
Apr 25 19:00:59 c4 kernel: eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1]
WireSpeed[1] TSOcap[1]
Apr 25 19:00:59 c4 kernel: eth2: dma_rwctrl[76180000] dma_mask[64-bit]
Apr 25 19:00:59 c4 kernel: tg3: eth0: Link is up at 1000 Mbps, full
duplex.
Apr 25 19:00:59 c4 kernel: tg3: eth0: Flow control is on for TX and on for
RX.
Apr 25 19:00:59 c4 kernel: r8169: eth2: link up
Apr 25 19:00:59 c4 kernel: r8169: eth2: link up
Apr 25 19:01:01 c4 ntpd[2461]: Listening on interface eth2,
192.168.2.4#123 Enabled
Apr 25 19:01:01 c4 ntpd[2461]: Listening on interface eth0,
192.168.1.24#123 Enabled
Apr 25 19:01:01 c4 ntpd[2461]: Listening on interface eth1,
192.168.2.3#123 Enabled
Apr 25 19:01:08 c4 uxmon: c4.net: started monitoring: lo eth2 eth0 eth1
Apr 25 19:01:18 c4 kernel: tg3: peth0: Link is up at 1000 Mbps, full
duplex.
Apr 25 19:01:18 c4 kernel: tg3: peth0: Flow control is on for TX and on
for RX.
Apr 25 19:01:18 c4 kernel: device peth0 entered promiscuous mode
Apr 25 19:01:18 c4 kernel: type=1700 audit(1240678878.244:3): dev=peth0
prom=256 old_prom=0 auid=4294967295 ses=4294967295
Apr 25 19:01:18 c4 kernel: eth0: topology change detected, propagating
Apr 25 19:01:18 c4 kernel: eth0: port 1(peth0) entering forwarding state
Repeated booting sometimes gives me a different order, e.g. the two tigon
come first, but this is rare.
Well, it seems this wasn't a problem until I added a virtual interface to
eth0. When the eth interfaces are brought up the system seems to
reenumerate the eth numbering according to the HWADDR matches and thus
eth0=NIC1 and so on. As soon as I add a virtual interface to eth0 this
breaks and all of eth0 is killed. At least that's what I figure.
So, the next obvious question is: How can I set a fixed order, so that
NIC1 is always brought up first as eth0?
I'm not sure if this would fix it, though. I have done too few reboots
yet, but it seems that at least once I got the "correct" initialization
order but eth0 got killed, anyway. So, it might not be the order but still
something in the Xen script which happens only when multiple NICs are
present and a virtual interface is added.
Any thoughts so far?
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
James Matthews <nytrokiss(a)gmail.com> wrote:
>>
I am wondering how I would interpret the "load average: 0.00, 0.01, 0.00"
within the uptime.
<<
See man 3 getloadavg.
Best,
--- Les Bell
[http://www.lesbell.com.au]
Tel: +61 2 9451 1144