Re: [CentOS] Bastille-linux
On Thu, Jun 2, 2011 at 7:57 PM, Bob Hepple wrote: > Has anyone got Bastille-linux running on Centos-5.6? Nope, but I have a hardening document that I wrote up for an earlier version of Red Hat that might be applicable -- I incorporated the Bastille recommendations into my documentation rather than just running the package because I wanted to know what each thing was doing. Let me know if you'd like me to see if I can dig that up. Regards, M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Grep: show me this line and the next N lines?
On Mon, May 30, 2011 at 5:08 PM, Dotan Cohen wrote: > Can grep show the matching lines and the next N lines after a match? > > I would ideally grep on "[Tag h1]" and have grep display the match and > the next 5 lines so that I see all the content of the h1 section. > Try grep -A 5 pattern filename M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] securing ldap with tls and security
On Tue, May 24, 2011 at 4:52 PM, Scott Robbins wrote: > I'm going to post a link to my own page on it---which has links to other > pages. Among other things, it goes through TLS. > > http://home.roadrunner.com/~computertaijutsu/ldap.html Scott, I didn't read through the whole document, but yours is one of the most complete and useful ones that I've seen. Definitely a great resource for anyone setting up an OpenLDAP server for the first (or fifth) time. Regards, M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] what process is sending this packet?
On Mon, Dec 27, 2010 at 9:30 AM, S Mathias wrote: > Dec 27 14:11:46 a kernel: [ 6336.992320] O_D_LOG: IN= OUT=lo SRC=127.0.0.1 > DST=127.0.0.1 LEN=60 > TOS=0x00 PREC=0x00 TTL=64 ID=61533 DF PROTO=TCP SPT=37263 DPT=25 WINDOW=32792 > RES=0x00 SYN URGP=0 > but where or how could i find out, that what process sends these packets? Looks like mail traffic -- check /var/log/maillog and see what's being recorded there and who the recipient is. My guess is that it's a local recipient and you'll be able check out the local mail files on that system to see what the content is and determine from that which process is sending out the messages. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] generate signing subkey
On Thu, Nov 4, 2010 at 4:27 PM, Tim Dunphy wrote: > I need to generate a subkey in gpg in order to sign my emails. I > already have a main key. how do I generate the subkey I need to > encrypt emails? I have already run gpg --gen-key http://www.gnupg.org/gph/en/manual.html#AEN282 explains how to generate a subkey. You may also find this blog post useful: http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/ HTH, M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] trouble mounting NFS share in net install
> The nas host in question is a freenas which I believe is NFS 4. I can > / will verify if someone would care to respond to this thread. > > but when I go to do the same thing in the centos net install I get an > error stating simply: "that directory cannot be mounted from the server". Is the FreeNAS configured to permit the new machine you are building to mount the share? http://freenas.org/documentation:setup_and_user_guide:services_nfs_shares shows where the settings for that are... M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Slow domain resolution problem
On Mon, Aug 23, 2010 at 11:08 AM, Gabriel Tabares > One more thing, if this is the case, why does the nslookup respond > straight away? Is the destination server trying to somehow validate the > host where the connection came from? It's entirely possible (and probable) that the mail server is attempting to do a reverse looking up the originating host. When the lookup times out, the connection goes through. If the command ping my-mail02.mydomain.com returns immediately with data, that would support that theory. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Upgrading MySQL
> django.core.exceptions.ImproperlyConfigured: MySQLdb-1.2.1p2 or newer is > required; you have 1.2.1 To identify what package contains a specific file, you can use yum search. For example: yum search MySQLdb returns MySQL-python.x86_64 : An interface to MySQL therefore MySQLdb can be updated by updating MySQL-python. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] resolv.conf rewritten every reboot. How to figure out who and why?
> /etc/sysconfig/network-scripts/ifup-eth: BOOTPROTO=bootp
> So, it's not PEERDNS, not DHCP, not NetworkManager. Why is dhclient-script
> even being run?
BOOTPROTO=bootp is triggering it.
In /etc/sysconfig/network-scripts/ifup-eth:
if [ "${BOOTPROTO}" = "bootp" -o "${BOOTPROTO}" = "dhcp" ]; then
DYNCONFIG=true
fi
Then, later on in that script:
if [ -n "${DYNCONFIG}" -a -x /sbin/dhclient ]; then
do a bunch of stuff related to dynamically assigned addresses and names.
And finally:
if /sbin/dhclient ${DHCLIENTARGS} ${DEVICE} ; then
echo $" done."
else
> Maybe I should disable selinux altogether, instead of just making it
> permissive? I think I'll try that.
selinux shouldn't have anything to do with the resolv.conf file being
rewritten -- unless it's set to enforcing and something that isn't
allowed to do so is trying to rewrite the file.
HTH,
M
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
> But these aren't SMTP connections. The source is port 25, but the > destination is not. The mail server is running normally. I'm allowing > new SMTP connections and traffic for established connections. They are SMTP connections -- your server initiates a connection to port 25 on the remote server. Thus, when the connection is set up the remote server will be responding with source port 25 and destination port = source port of the initiated connection. > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state > RELATED,ESTABLISHED > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW > tcp dpt:25 I think the ACCEPT all line should catch these, but you might try adding RELATED,ESTABLISHED specifically to the dpt:25 line. > # cat /proc/sys/net/ipv4/ip_conntrack_max > 63480 Unless you're passing a lot of traffic, the conntrack_max looks okay. > >> Yet another possibility is that these are duplicated packets (for >> whatever reason) and the connection has already been closed out. >> > > Possible, I guess, but I don't know what would be duplicating them. This isn't as likely, but the remote sites could be duplicating them -- the only way to determine if that's the case would be to sniff the traffic and see if the remote site sends the same packet more than one. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
> conversation. The question is: why are all of these remote servers > trying to make connections back to me on high-numbered ports? Should I > be allowing these connections somehow? The remote server probably thinks that it's still supposed to be making connections back to you -- a couple of the lines you posted showed FIN flags indicating that the TCP connection was being shut down. At that point, the mail message has already been sent. If you get REJECT messages for all SMTP connections, look at your iptables rules and see if you have a specific rule for smtp that only permits NEW conns. One possibility is that iptables no longer thinks that the connection is active -- possibly the connection tracking database has already pushed that connection out. You can check your conntrack max value with the command cat /proc/sys/net/ipv4/ip_conntrack_max Yet another possibility is that these are duplicated packets (for whatever reason) and the connection has already been closed out. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] resolv.conf rewritten every reboot. How to figure out who and why?
On Thu, Oct 8, 2009 at 5:39 PM, Dave wrote: > On Thu, Oct 8, 2009 at 11:27 AM, Meenoo Shivdasani wrote: >> /etc/init.d/network calls /etc/sysconfig/network-scripts/ifup which >> calls /sbin/dhclient which calls /sbin/dhclient-script which >> overwrites your resolv.conf with the info it gets from the DHCP server >> on the network. > > And it seems not to be correct. > At least, if /etc/sysconfig/network-scripts/ifup calls > /sbin/dhclient, it must use some indirection, as dhclient is not > mentioned in the script explicitly: My bad -- on the 4.x system I referred to, ifup is where it's called. On my 5.x system, it's called by ifup-eth. > Why does it overwrite /etc/resolv.conf when the machine is not set to > use DHCP? The IP address etc. is set statically using > /usr/bin/system-config-network. Are there any interfaces that have BOOTPROTO=dhcp? Perhaps one that's not connected to the network? grep BOOTPROTO /etc/sysconfig/network-scripts/ifcfg* > How would I find this out on my own? That's a harder one to answer. I would start with the comment that got added to the resolv.conf file -- and Google resolv.conf dhclient. That brings up hits that describe several ways of avoiding the whole issue (and confirms for you that you're on the right track). man dhclient mentions dhclient-script, then poking around in various etc directories gets you to where it gets called from. Making the leap to figuring out that PEERDNS is one of the ways that you can control whether or not resolv.conf gets modified would mean looking through the various definitions in ifcfg-eth0 and making sure that you know what each one does. When you hit one that you don't recognize, look it up. In this case: PEERDNS=, where is one of the following: yes — Modify /etc/resolv.conf if the DNS directive is set. If using DCHP, then yes is the default. no — Do not modify /etc/resolv.conf. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] resolv.conf rewritten every reboot. How to figure out who and why?
> You guessed right. But the question remains, what software is writing the > file? /etc/init.d/network calls /etc/sysconfig/network-scripts/ifup which calls /sbin/dhclient which calls /sbin/dhclient-script which overwrites your resolv.conf with the info it gets from the DHCP server on the network. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] resolv.conf rewritten every reboot. How to figure out who and why?
On Thu, Oct 8, 2009 at 1:41 PM, Dave wrote: > My machine has a static IP, with dhcp and IPv6 disabled. Every time I > reboot, some process rewrites /etc/resolv.conf, including a comment > about dhcpclient. The only package I have installed that shows up in > "rpm -qa|grep -i dhcp" is dhcpv6-client-1.0.10-16.el5, and nothing in > there is named dhcpclient. Looks like the dhclient script is still being called. One option would be to comment out the make_resolv_conf() function in /sbin/dhclient-script. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] selinux...
> Then we can go to:
> <...> avc: denied { write } for pid=5898 comm="LLAWP"
> path="/var/log/httpd/smagent.log" dev=sda3 ino=
> scontext=root:system_r:httpd_t:s0 tcontext=root:object_r:httpd_log_t:s0
> tclass=file
When selinux is configured for permissive mode, the action is
permitted, but selinux still logs a denial message -- if the mode is
set to "enforcing" then the action itself would be denied and a denial
message would be logged. Permissive mode shows you what things would
be denied, but doesn't actually deny them.
Basically, what's happening with your siteminder app is that the
selinux policy doesn't permit the source executable context to write
to the smagent.log file due to the file's context.
Check out
http://www.linuxforums.org/articles/accomodating-avc-denied-messages-selinux_355.html
This explains how to decipher the denial message and how to use
audit2allow to specifically permit your application to write to the
appropriate log file.
HTH,
M
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum update
On Thu, Aug 13, 2009 at 7:59 AM, madunix wrote: > Can any one clarify this, is auto updating at all production servers > recommended or not? > need to know your opinion, how do you manage the update? For a production server, I don't auto-update. There are too many variables involved that may negatively affect the server's functions. When implementing updates, I prefer to plan ahead, test on a non-critical server, create a change plan that includes a roll-back plan, and then schedule an outage window that allows enough time to revert to the original version if necessary. If it's a minor update that should not in any way negatively affect a production system, I might skip scheduling an outage window, but I'll still have a roll-back plan. This may be an overly cautious approach, but it's the one that I use for production systems. HTH, M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Suggestion on Network Management software with troubleticket system
> In my current small-ish setting, I use Trac for tickets and documentation. I > keep most configuration files in a Subversion repository (an export of which > serves as the depot for cfengine) -- and Trac makes it easy to link between > wiki pages, tickets, and repository revisions. I second the recommendation for Trac + Subversion for ticketing, documentation, + revision history. > I don't think this setup would scale to a large organization, but it works > just fine in smaller environments. For a large organization that needs a full-blown ticketing system, RT is applicable, but it's really cumbersome to set up if you just need a fairly small system. > Nagios, like cfengine, takes a while to get started, but does the job once > it's up and running. Wolfgang Barth's book from No Starch Press can be handy > to have around if you want an accessible introduction and reference. And, for monitoring, I second the vote for Nagios -- very customizable. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bind9, SELinux, ServFail
On 7/10/08, Filipe Brandenburger <[EMAIL PROTECTED]> wrote: > Did you update the "selinux-policy" package at the same time? > Well, I'm almost positive that is what you are missing. Filipe, You nailed it. That was what I was missing. Many thanks, M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bind9, SELinux, ServFail
On 7/10/08, Meenoo Shivdasani <[EMAIL PROTECTED]> wrote: > > SELinux is preventing BIND to open port UDP/16660. Did you configure > > BIND to use that specific non-standard port? > > > I installed the latest version of BIND which randomizes the source > port...do you think that's the problem? If so, how do I get SELinux > to accept it? To be more accurate, I installed the patched version of BIND which randomizes the source port to address the latest DNS vulnerability. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bind9, SELinux, ServFail
> SELinux is preventing BIND to open port UDP/16660. Did you configure > BIND to use that specific non-standard port? I installed the latest version of BIND which randomizes the source port...do you think that's the problem? If so, how do I get SELinux to accept it? M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bind9, SELinux, ServFail
> If it's SELinux related, have a look at /var/log/audit/audit.log, that
> will tell you what is being blocked in SELinux. That would be a good
> start. Let us know what you found there, then we might be able to help
> you a little more.
That's a huge help -- didn't occur to me to look in audit.log -- that
said, I'm not entirely sure what SELinux is doing here (other than
denying the connection). Or, to be more accurate, I don't understand
why it's denying the connection, therefore don't know how to make it
behave...
type=AVC msg=audit(1215740151.446:796): avc: denied { name_bind }
for pid=21081 comm="named" src=16660
scontext=root:system_r:named_t:s0 tcontext=system_u:object_r:port_t:s0
tclass=udp_socket
type=SYSCALL msg=audit(1215740151.446:796): arch=c03e syscall=49
success=no exit=-13 a0=1f a1=43c8ed40 a2=1c a3=43c8eb3c items=0 ppid=1
pid=21081 auid=0 uid=25 gid=25 euid=25 suid=25 fsuid=25 egid=25
sgid=25 fsgid=25 tty=(none) ses=60 comm="named" exe="/usr/sbin/named"
subj=root:system_r:named_t:s0 key=(null)
Ideas & thoughts welcome...
Thanks,
M
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] bind9, SELinux, ServFail
I just set up a CentOS 5.2 system with bind9 (9.3.4-6.0.1.P1.el5) and I'm running up against a problem that seems to be related to SELinux. If I set named_disable_trans to 1, everything works as expected, but if I leave it enabled the server will only give me data for the zones for which it is authoritative. For external sites it returns a ServFail error. This is with nslookup and dig. If I start named from the command line with the command "named -u named", the server returns the expected response. tcpdump shows that the server is querying itself and getting a ServFail response. I figure that I'm missing something really basic, but not sure what. Debug logs show this: FAIL: clientmgr @0x2b491728c1d0: createclients clientmgr @0x2b491728c1d0: recycle . . . fctx 0x2b49173153e0(www.google.com/A'): shutdown client 192.168.213.111#33096: view internal: error Succeed: clientmgr @0x2b109771bd30: createclients clientmgr @0x2b109771bd30: create new . . . res 0x2b109778cae0: dns_resolver_prime res 0x2b109778cae0: priming createfetch: . NS fctx 0x2b109781e280(./NS'): create fctx 0x2b109781e280(./NS'): join fetch 0x2b109781e260 (fctx 0x2b109781e280(./NS)): created dns_adb_createfind: found A for name 0x2b109780fa70 in db fctx 0x2b109781e280(./NS'): start res 0x2b109778cae0: dns_resolver_prime fctx 0x2b109781e280(./NS'): try fctx 0x2b109781e280(./NS'): cancelqueries fctx 0x2b109781e280(./NS'): getaddresses dns_adb_createfind: found for name 0x2b109780fa70 . . . Any ideas? Thanks in advance, M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Message size rejected
> [EMAIL PROTECTED] > SMTP error: 552 5.3.4 Message size exceeds fixed limit > Reporting-MTA: dns; borg2.lydgate.lan > > I presume that this is a configurable limit, but I'm not sure where to look. > Since it says MTA I'm thinking that it's probably postfix. Can someone > please tell me what parameter I'm looking for? Thanks If it's postfix, the parameter is message_size_limit -- the default is 1024 (10MB) if it's not explicitly configured. This parameter goes in main.cf. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] udevd can't reach LDAP-server during boot
On Tue, Jun 24, 2008 at 3:44 PM, Johnny Hughes <[EMAIL PROTECTED]> wrote: > There is a BUG with nss_ldap: > > https://bugzilla.redhat.com/show_bug.cgi?id=448014 > > We have this bug listed in our release notes: > > http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.2#head-447967c60eb305ef2c5dbbc3f4e8b3c4c5170632 > > You can try the nss_ldap from our testing repo for this bug: > > http://dev.centos.org/centos/5/ > > This may help with the problem. FWIW, my experience with a variant of this problem and nss_ldap from the testing repo was that boot would hang indefinitely at udevd unless I limited the nss_reconnect_* values. I ended up changing to bind_policy soft as a workaround. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
nss_ldap (was Re: [CentOS] Could this be an advantage of CentOS over the PNAELV distribution?_
> There is a bug with nss_ldap and bash32 ... I created a new RPM for the > nss_ldap that is currently in our testing repo. Johnny, I was wondering if that RPM includes the security fixes detailed in https://rhn.redhat.com/errata/RHSA-2008-0389.html Thanks in advance, M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
