Re: [CentOS] init/upstart issue? ypbind and autofs
> | The other machine doesn't have NetworkManager installed. Removed it > | here > | and NIS/autofs started working correctly. > > You don't have to remove NetworkManager you just need to tell the interface > not to be managed by NM in order for it to work. Won't help in this case, I think, as this behaviour already makes my kickstart %post fail. > | Why again did RH switch to NM? > > To better support mobile devices like laptops and to make network > configuration easier for new GNU/Linux users. Well, I appreciate NM on laptops, but this is a distro geared towards enterprise. I can't imagine many enterprise users running a distro on laptops where most software components are already outdated upon release and support for newer hw may be sketchy. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Dovecot problems
I'm not sure I understand all of the consequences of just moving these folders from /home/user/mail to the new servers. So far, I seem to have things working OK with a pop, imap, and horde webmail situation for any particular account. It required using "namespace", but it seems to work. Can anyone give me a little heads-up on what to expect by doing things this way? Thanks so far for all the help. steve On 2/13/2012 3:31 PM, Peter Peltonen wrote: > Hi, > > On Mon, Feb 13, 2012 at 7:43 PM, Les Mikesell wrote: >> If you need to convert formats or copy between machines, there is a program >> called imapsync that will connect as a client to two imap servers and sync >> the folder structure. You could probably also switch to cyrus if you use >> that to do the copy. > +1 for imapsync, I've migrated many imap accounts from different > servers with it. > > It's available in the rpmforge repositry. > > Best, > Peter > ___ > 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] [CentOS-announce] CEBA-2012:0124 CentOS 6 kernel Update
On 02/14/2012 06:00 AM, Johnny Hughes wrote: > CentOS Errata and Bugfix Advisory 2012:0124 > > Upstream details at :https://rhn.redhat.com/errata/RHBA-2012-0124.html > > The following updated files have been uploaded and are currently > syncing to the mirrors: ( sha256sum Filename ) > > > i386: > 73849c1b3103e62ef1f469d189d36e306b2a5c38ac1e03a23bb82ca569f33ded > kernel-2.6.32-220.4.2.el6.i686.rpm > 283cf06274026bbce4894aaa46cf3a7b8eb3d950e707bce79df1b4744c2256fe > kernel-debug-2.6.32-220.4.2.el6.i686.rpm > ccacf5db5d9ec3c08ab9b1cf913ccc19c2cf638570d5b304bab10fb0379e682c > kernel-debug-devel-2.6.32-220.4.2.el6.i686.rpm > 3e4059a495c06656f9366c168899da4f7b9be2d4dd7d5b3b85b181d5bec1c8a6 > kernel-devel-2.6.32-220.4.2.el6.i686.rpm > 15eedf5373ef236ccd3f359dddf98a79bab7d6d73303207ecb8c1d8ad047ba55 > kernel-doc-2.6.32-220.4.2.el6.noarch.rpm > c415cdb090b59dcc80e13054012e45f23bf8e3cc1245a1f85aaf5d1cc791bc86 > kernel-firmware-2.6.32-220.4.2.el6.noarch.rpm > 7a9d72cd977f044ea24eba24a46bee0dedb112fe19d7f3aa6b9fe945d61663d5 > kernel-headers-2.6.32-220.4.2.el6.i686.rpm > 125120985bd7d7a83b4ccd9330affa64ace446f96b2a9a2121219745afdf621e > perf-2.6.32-220.4.2.el6.i686.rpm > 925edef043f1f863ddf8d6b55040e7fce58c3185e276c33953a754a6c64116a1 > python-perf-2.6.32-220.4.2.el6.i686.rpm > > x86_64: > e7c8f813ef1ebc783811894d3143c3965c20c3312ad65fc4e1cf73f9afc29155 > kernel-2.6.32-220.4.2.el6.x86_64.rpm > 4e2c367554292ed66d991b24917948001877a995f50d03c54047c57cee470377 > kernel-debug-2.6.32-220.4.2.el6.x86_64.rpm > 58631186f2babbc46918e67f91760663f85235dc837b5695efbd97696b59c158 > kernel-debug-devel-2.6.32-220.4.2.el6.x86_64.rpm > 78b63a80fd7a8af3083d5b07e35ddd74cd9993c38ac1a67240774b08954f38a0 > kernel-devel-2.6.32-220.4.2.el6.x86_64.rpm > b69c65bad8e5bc58f9128d893b1a3e93c3dcc1e633b70fbeaa88c70f9568b510 > kernel-doc-2.6.32-220.4.2.el6.noarch.rpm > a0b8dadc909efb4d7b832bff405fd8c255bc0401a6123c96b3421c5c9600eb0b > kernel-firmware-2.6.32-220.4.2.el6.noarch.rpm > 4bb63941d75b8c3334e2d9da2a4df1b812de1cb308bcaafd6161a06eba5d0469 > kernel-headers-2.6.32-220.4.2.el6.x86_64.rpm > 89612ecf638034983e045e978fada0b9885eec21fae3cd59ad714c06fb4b8936 > perf-2.6.32-220.4.2.el6.x86_64.rpm > de66cf4e775d1f4f8b652780c5d9c05bed629e3911696ffad03baeb891a22c20 > python-perf-2.6.32-220.4.2.el6.x86_64.rpm > > Source: > f412dbb7b1e7b0061c68fd6ad84960a47d0270fec644071ebd9583fc7a1b3290 > kernel-2.6.32-220.4.2.el6.src.rpm > > > Anyone know how to tell if your system is using: "This overflow led to a kernel panic on the systems using the Time Stamp Counter (TSC) or Virtual Machine Interface (VMI) clock source" -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 84, Issue 7
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org
You can reach the person managing the list at
centos-announce-ow...@centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."
Today's Topics:
1. CESA-2012:0125 Moderate CentOS 4 glibc Update (Johnny Hughes)
2. CESA-2012:0126 Moderate CentOS 5 glibc Update (Johnny Hughes)
3. CESA-2012:0127 Moderate CentOS 5 mysql Update (Johnny Hughes)
4. CEBA-2012:0124 CentOS 6 kernel Update (Johnny Hughes)
5. CEBA-2012:0123 CentOS 6 selinux-policy Update (Johnny Hughes)
6. CEBA-2012:0122 CentOS 6 squid Update (Johnny Hughes)
7. CESA-2012:0128 Moderate CentOS 6 httpd Update (Johnny Hughes)
--
Message: 1
Date: Tue, 14 Feb 2012 02:09:08 +
From: Johnny Hughes
Subject: [CentOS-announce] CESA-2012:0125 Moderate CentOS 4 glibc
Update
To: centos-annou...@centos.org
Message-ID: <20120214020908.ga23...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2012:0125 Moderate
Upstream details at : https://rhn.redhat.com/errata/RHSA-2012-0125.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
c40f7a3d1091ec0ce10233b49f58cfaf8a9a59380e44fe61303b3e22124a345c
glibc-2.3.4-2.57.i386.rpm
0cd5a29747b75107645f7593bcfbea4150ab09b81fde25251ffb99e2335a9d9a
glibc-2.3.4-2.57.i686.rpm
777342a29d5119a54948b15b42dca4b38ab458b2756287504736c538daf4218b
glibc-common-2.3.4-2.57.i386.rpm
1da90467a7f9a0c502c10621914adc7141801bb420af5a4daac63e2c4011c2f5
glibc-devel-2.3.4-2.57.i386.rpm
4c4815c05c4c8221434e644adce61639a9d3b3ee0485ca7d9665da5fce55a48f
glibc-headers-2.3.4-2.57.i386.rpm
d82703d3f2aef5ea8d02e3ec34b00c8e4bbfc77acf9c3fa42ef7df6d725698ff
glibc-profile-2.3.4-2.57.i386.rpm
7ccfd9542eeb6cd39cbc21512b0ebef1580f24638951078cd43ff7c8e12c3fd3
glibc-utils-2.3.4-2.57.i386.rpm
e097a2fee2201835a8c6484e2ab75c7be6a7252c12f3a267a30ef268d460e658
nptl-devel-2.3.4-2.57.i386.rpm
5a57d7429d04740e3f445a954ecfed2b6d5e251cadf3a4c2f10b7b9307d2fe8e
nptl-devel-2.3.4-2.57.i686.rpm
9a4f1fb8d99c4374d18214a0c91d33691a7d3a0611f933cb175d201719f9868a
nscd-2.3.4-2.57.i386.rpm
x86_64:
0cd5a29747b75107645f7593bcfbea4150ab09b81fde25251ffb99e2335a9d9a
glibc-2.3.4-2.57.i686.rpm
51b5c9bd1edd6b7fe5fdc4041ed1643040f263c28f53574d9d05bc06133665c5
glibc-2.3.4-2.57.x86_64.rpm
01140b88c80d3ce839401863d0b9fcc36af1ee4cb9d06b1bb29b60482fb8c89f
glibc-common-2.3.4-2.57.x86_64.rpm
1da90467a7f9a0c502c10621914adc7141801bb420af5a4daac63e2c4011c2f5
glibc-devel-2.3.4-2.57.i386.rpm
8924ccfee2a8376bdc9a330be8bd0060e030b62b1a003570dd6723844c3c5f09
glibc-devel-2.3.4-2.57.x86_64.rpm
cf013d0c5ab9560d690051f334fb0c311a9d4d74c3cfd68fa15eab0beb68cfc7
glibc-headers-2.3.4-2.57.x86_64.rpm
4c1037e641c56dc67595f6d859bffab54abe6f739bcad036b93d7c517719f013
glibc-profile-2.3.4-2.57.x86_64.rpm
774846ce4a93f60d6a5d8837c24d6b51e98b953a7a4e88bdcc94ad6be58e0519
glibc-utils-2.3.4-2.57.x86_64.rpm
245417fe4d7d3536a47cc05e09d7200195e250881d3f8e628c62a4d8f85afb45
nptl-devel-2.3.4-2.57.x86_64.rpm
ef0447e007436d3d06fe912edfd7067f08c6e5f68ff871af2365cdd9d45c557d
nscd-2.3.4-2.57.x86_64.rpm
Source:
b05896a97fe1fd5f75bb117ef9f21f9ad239442f76862c1c607f3a8d2083ac77
glibc-2.3.4-2.57.src.rpm
--
Tru Huynh
CentOS Project { http://www.centos.org/ }
irc: tru_tru, #cen...@irc.freenode.net
--
Message: 2
Date: Tue, 14 Feb 2012 03:06:54 +
From: Johnny Hughes
Subject: [CentOS-announce] CESA-2012:0126 Moderate CentOS 5 glibc
Update
To: centos-annou...@centos.org
Message-ID: <20120214030654.ga26...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2012:0126 Moderate
Upstream details at : https://rhn.redhat.com/errata/RHSA-2012-0126.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
490a1c39e8d95240f11fc11e080b264d237244e3943dbece83f29665c5650b13
glibc-2.5-65.el5_7.3.i386.rpm
a743515f16ef94e620e886ce7b0421097ea8e9c5237c191146f3febd469a628f
glibc-2.5-65.el5_7.3.i686.rpm
93f45c442e308c0a1257fbd3f35d145c6d4def3c8eaf8d70a3fd78871a61ef56
glibc-common-2.5-65.el5_7.3.i386.rpm
f1528565a36be720abe89ec7e886a3bd8b541fa477dae2a3e9eb28b75ab5fcf2
glibc-devel-2.5-65.el5_7.3.i386.rpm
6e48064b2e532068094992f3735ea27e1fe1cc7552e0757eda65fd0685ccace8
glibc-headers-2.5-65.el5_7.3.i386.rpm
0121d1004b8df564e4ad717e55de16d2c3bcdae987bab39c87d19da2eefb652c
glibc-utils-2.5-65.el5_7.3.i386.rpm
f437b270582fcd0154b5ad5558d810418999dc4966e224
Re: [CentOS] schily tools
Les Mikesell wrote: > > Well, I verified that gtar fails with even a simple case and I did not see > > any > > problem with star since 6 years even with thousands of incremental > > restores. > > So I am not sure what you are talkin about. > > > > Gtar doesn't fail, it just requires some extra steps to accommodate some > very unlikely circumstances. Your star runs will not work at all in very > likely circumstances (which you conveniently avoid testing). Trying to understand you leads me to the assumption that you of course know that gtar fails. As you seem to claim that there is a workaround but don't mention it, it seems that you like other people to fail when trying to restore incremental backups that have been made with gtar. > > How many successful automatical incremental restores did you try with gtar > > so > > far? 1/12 dozen? > > > > Enough to know it works. Well, I did one test only and I know that gtar does not do what it should when restoring incrementals. In addition, gtar incrementals are not space efficient: If you e.g. have a 1 TB filesystem with one directory at top level and rename that directory, you will end up with a 1 TB incremental if you use gtar. Looking at the way gtar works, I would assume that gtar needs an intermediate disk space of 2 TB to restore the data (if the restore works at all). Star will create an incremental archive of 10kB for the same change and star does not need additional space on the restore media. Also note that star is able to backup ACLs and extended attributes but gtar does not have the needed features to do so. > Our definitions of 'OS and FS independent' are very different. I expect > that to mean that I can actually change the FS and have things keep > working. Star doesn't. And it doesn't work over nfs, on fat, ntfs, and on > and on. Do you like to tell everbody that it makes no sense to believe you, or why do you write claims that are obviously wrong? Star gives you FS and OS independence and star is even at least 30% faster than ufsdump (under all conditions) or any fork that was created from ufsdump (such es ext*..). > What rules? If you are FS independent, you follow a directory tree, not a > rulebook. I want the content of my files backed up whether they are stored > in a way that matches your restricted rules or not. I don't want to have > to take a whole filesystem. I don't want a run to be restricted to a > single filesystem. You again harm your credibility by writing false suggestions. Star of course allows you to backup parts of a filesystem (e.g. a directory sub-tree). It seems that your problem is that you are not willing to inform you about any other program that gtar and it seems that you are not willing to think about the results from gtar problems. > In a word, amanda. If my backups don't fit on the tape there are no > backups at all, and the only reason for doing incrementals at all is that > you have to use them to make the data fit. I'm not interested in > calculating the right mix of incremental levels on a whole bunch of > directory trees to make each night's run fit. Amanda does that You again harm your credibility by writing false suggestions. Star is able to automatically deal with the unpredictable size of modern tapes with HW compression, while amanda fails completely and needs to assume the smallest possible size. This is because amanda does not make use of the related features of the backup utility. Star can detect the actual end of a tape in write mode on the fly and then request a media change. BTW: what amanda does may make sense with gtar as gtar frequently fails to accept own followup volumes but this is a problem that is absent with star. > automatically. Amanda can use dump or gnutar. Linus Torvald has claimed > that dump is not safe on live filesystems. I assume he's an expert on the > topic (and without looking at the code, I'd guess that star uses the same > approach to determine what to take in incrementals). That leaves gnutar. Well, besides the fact that Torvalds is not known of being a filesystem expert it is a bad idea to invert a true claim as you do here and believe that this is still true. ufsdump is not safe on life filesystems but gtar and star are not safe too. The most insecure backup program for a life file system if ufsdump or it's forks. This is because ufsdump first reads all fs meta data and later reads a raw filesystem at block level without taking care of changes. gtar is still insecure as it traverses the directory tree and is affected by changes on that tree while the backup is running. star is definitely less insecure than gtar as star does not need to keep a database of the filesystem structure in order to be able to work. In any case, I know of no serious sysadmin that makes backups from a life filesystem without using filesystem snapshots. If you however use snapshots that are needed for a reliable incremental backup,
Re: [CentOS] QEMU configuration not persistent
On Mon, 13 Feb 2012, Emmett Culley wrote: > Still doesn't persist. Each time I reboot I have to use > virt-manager to change video to cirrus from vmvga, then remove the > IDE driver that points to the wrong storage location and add a new > virtio storage device pointing to the correct image (an LVM > partiiton). > > After I make the changes I close virt-manager and restart it, then > look at the configuration for the non-persistent VM, and my changes > are still there and I can run the VM. > > I did a "grep vmvga" on the entire /etc/libvirt directory tree and > found no references to "vmvga". Where can libvirt be getting info > to change the xml to vmvga, or the IDE to the wrong location? I've not seen these symptoms, so I can only outline the sorts of steps I'd take in troubleshooting. First, I'd check for SELinux issues: 1. Run "fixfiles check /etc" to see if a configuration file is mislabled. 2. Do the same thing on /var to see if any runtime files have issues. 3. Run "ausearch -m avc" and grep for qemu or libvirt issues. After that, I'd get more drastic: 1. virsh shutdown $DOM. 2. virsh dumpxml $DOM > /tmp/dom.xml 3. virsh undefine $DOM 4. virsh create /tmp/dom.xml 5. virsh edit $DOM 6. virsh start $DOM --console And then see if things get better. -- Paul Heinlein <> heinl...@madboa.com <> http://www.madboa.com/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bug in repo affecting perl
Nicolas Thierry-Mieg wrote the following on 2/13/2012 9:11 PM: > why do you think there's a problem? if you have an x86_64 system, you > are expected to use x86_64 perl, and that's what you have in the os > and updates dir for that arch, with the newer version in updates. Same > if you have an i386 system. Apparently centos extras provides the i386 > package for people who want that on an x86_64 system, although the > version provided is the older one. ... > The only possible "bug" is that extras could carry the latest i386 > package. I have dozens of x86_64 systems. On none of them did I manually install the i386 perl package. However, they all seem to have it installed. It seems that in many cases CentOS installs both an i386 and an x86_64 package when only the base package is requested, so I have thought nothing of it. install.log shows that the x86_64bit package was the only one initially installed, yum indicates that the i386 package was installed later (looks like during a yum update, possibly a dependency). Is this a past mistake in the repo that is only rearing its head when there is a mismatch between the x86_64 version in the update repo and the i386 version in the extra repo? Should there even exist a version in the extra repo? If so, it seems it should certainly be updated. --Blake ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] iptables nat PREROUTING chain
Is there a way to add a rule to the nat table (CentOS 5.7) that would alter the port number of tcp packets destined for the server itself? I have ip_forwarding enabled, but the packets don't seem to hit the prerouting chain. I have the following redirect rule in the prerouting table. I also tried DNAT, but if the packets don't hit PREROUTING, it won't work either. iptables -t nat -L -v -n Chain PREROUTING (policy ACCEPT 16079 packets, 896K bytes) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- * * 10.10.10.0/24 0.0.0.0/0 tcp dpt:25 redir ports 12345 aspen 2# cat /proc/sys/net/ipv4/ip_forward 1 Thanks, Nataraj ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables nat PREROUTING chain
On Tuesday 14 February 2012 15:21, the following was written: > Is there a way to add a rule to the nat table (CentOS 5.7) that would > alter the port number of tcp packets destined for the server itself? I > have ip_forwarding enabled, but the packets don't seem to hit the > prerouting chain. > > I have the following redirect rule in the prerouting table. I also > tried DNAT, but if the packets don't hit PREROUTING, it won't work either. > > iptables -t nat -L -v -n > Chain PREROUTING (policy ACCEPT 16079 packets, 896K bytes) > pkts bytes target prot opt in out source > destination 0 0 REDIRECT tcp -- * * 10.10.10.0/24 >0.0.0.0/0 tcp dpt:25 redir ports 12345 > > > aspen 2# cat /proc/sys/net/ipv4/ip_forward > 1 Where are you applying this rule? On a firewall or on the SMTP server itself? If the firewall then you need to use DNAT Example: iptables -t nat -A PREROUTING -p tcp --dport -j DNAT --to-destination : If you only want this to happen on the inside of the firewall then you are also going to have to include the interface you want this rule to apply to. If it is on the SMTP server itself then you don't need forward to be turned on and you need to use REDIRECT Example: iptables -t nat -A PREROUTING -p tcp --dport -j REDIRECT --to-ports Also make sure no other rule is filtering the packets before this rule because if the packets are altered then this rule will never be used. -- Regards Robert Linux The adventure of a lifetime. Linux User #296285 Get Counted http://linuxcounter.net/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables nat PREROUTING chain
On 02/14/2012 01:28 PM, Robert Spangler wrote: > On Tuesday 14 February 2012 15:21, the following was written: > >> Is there a way to add a rule to the nat table (CentOS 5.7) that would >> alter the port number of tcp packets destined for the server itself? I >> have ip_forwarding enabled, but the packets don't seem to hit the >> prerouting chain. >> >> I have the following redirect rule in the prerouting table. I also >> tried DNAT, but if the packets don't hit PREROUTING, it won't work either. >> >> iptables -t nat -L -v -n >> Chain PREROUTING (policy ACCEPT 16079 packets, 896K bytes) >> pkts bytes target prot opt in out source >> destination 0 0 REDIRECT tcp -- * * 10.10.10.0/24 >>0.0.0.0/0 tcp dpt:25 redir ports 12345 >> >> >> aspen 2# cat /proc/sys/net/ipv4/ip_forward >> 1 > Where are you applying this rule? On a firewall or on the SMTP server itself? > > If the firewall then you need to use DNAT > > Example: > > iptables -t nat -A PREROUTING -p tcp --dport -j DNAT --to-destination > : > > If you only want this to happen on the inside of the firewall then you are > also going to have to include the interface you want this rule to apply to. > > > If it is on the SMTP server itself then you don't need forward to be turned > on > and you need to use REDIRECT > > Example: > > iptables -t nat -A PREROUTING -p tcp --dport -j REDIRECT --to-ports > > > Also make sure no other rule is filtering the packets before this rule > because > if the packets are altered then this rule will never be used. > > Thank you. You've confirmed that the redirect that I have should work. I think I know what the problem is now. I have the NOTRACK bit set for incoming packets on port 25, so maybe those packets don't hit the nat PREROUTING table. I did that because spambot attacks were causing resource exhaustion problems in the kernel when it was tracking all of the connections. I don't really know how to do what I want to do other than increasing the resource on the server so it could sustain a spambot attack while tracking the connection. If you have any ideas it would be appreciated. What I am trying to do is to change my external SMTP port so that it does not allow relaying or authentication and move all of the relay clients to a submission port. The idea is to rewrite the port on connections coming from the internal network so we don't have to require all of the internal clients to reconfigure their mail clients. Nataraj ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [SOLVED] iptables nat PREROUTING chain
On 02/14/2012 02:39 PM, Nataraj wrote: > On 02/14/2012 01:28 PM, Robert Spangler wrote: >> On Tuesday 14 February 2012 15:21, the following was written: >> >>> Is there a way to add a rule to the nat table (CentOS 5.7) that would >>> alter the port number of tcp packets destined for the server itself? I >>> have ip_forwarding enabled, but the packets don't seem to hit the >>> prerouting chain. >>> >>> I have the following redirect rule in the prerouting table. I also >>> tried DNAT, but if the packets don't hit PREROUTING, it won't work either. >>> >>> iptables -t nat -L -v -n >>> Chain PREROUTING (policy ACCEPT 16079 packets, 896K bytes) >>> pkts bytes target prot opt in out source >>> destination 0 0 REDIRECT tcp -- * * 10.10.10.0/24 >>>0.0.0.0/0 tcp dpt:25 redir ports 12345 >>> >>> >>> aspen 2# cat /proc/sys/net/ipv4/ip_forward >>> 1 >> Where are you applying this rule? On a firewall or on the SMTP server >> itself? >> >> If the firewall then you need to use DNAT >> >> Example: >> >> iptables -t nat -A PREROUTING -p tcp --dport -j DNAT --to-destination >> : >> >> If you only want this to happen on the inside of the firewall then you are >> also going to have to include the interface you want this rule to apply to. >> >> >> If it is on the SMTP server itself then you don't need forward to be turned >> on >> and you need to use REDIRECT >> >> Example: >> >> iptables -t nat -A PREROUTING -p tcp --dport -j REDIRECT --to-ports >> >> >> Also make sure no other rule is filtering the packets before this rule >> because >> if the packets are altered then this rule will never be used. >> >> > Thank you. You've confirmed that the redirect that I have should work. > I think I know what the problem is now. I have the NOTRACK bit set for > incoming packets on port 25, so maybe those packets don't hit the nat > PREROUTING table. I did that because spambot attacks were causing > resource exhaustion problems in the kernel when it was tracking all of > the connections. I solved this by adding an accept to the raw PREROUTING table for the IP addresses that needed to have the ports altered, so they did not have the NOTRACK bit set. Thank You, Nataraj ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bug in repo affecting perl
Blake Hudson wrote: > > > Nicolas Thierry-Mieg wrote the following on 2/13/2012 9:11 PM: >> why do you think there's a problem? if you have an x86_64 system, you >> are expected to use x86_64 perl, and that's what you have in the os >> and updates dir for that arch, with the newer version in updates. Same >> if you have an i386 system. Apparently centos extras provides the i386 >> package for people who want that on an x86_64 system, although the >> version provided is the older one. ... > >> The only possible "bug" is that extras could carry the latest i386 >> package. > > I have dozens of x86_64 systems. On none of them did I manually install > the i386 perl package. However, they all seem to have it installed. > > It seems that in many cases CentOS installs both an i386 and an x86_64 > package when only the base package is requested, so I have thought > nothing of it. install.log shows that the x86_64bit package was the only > one initially installed, yum indicates that the i386 package was > installed later (looks like during a yum update, possibly a dependency). > > Is this a past mistake in the repo that is only rearing its head when > there is a mismatch between the x86_64 version in the update repo and > the i386 version in the extra repo? Should there even exist a version in > the extra repo? If so, it seems it should certainly be updated. yes it should be udpated. I was just pointing out that the i386 version you have installed must have come from extras, since your x86_64 system cannot see the i386 versions available in the base+updates i386 repos that you showed in your original post. It seemed you were wondering why these versions were not being installed. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bug in repo affecting perl
Nicolas Thierry-Mieg wrote: > Blake Hudson wrote: >> >> >> Nicolas Thierry-Mieg wrote the following on 2/13/2012 9:11 PM: >>> why do you think there's a problem? if you have an x86_64 system, you >>> are expected to use x86_64 perl, and that's what you have in the os >>> and updates dir for that arch, with the newer version in updates. Same >>> if you have an i386 system. Apparently centos extras provides the i386 >>> package for people who want that on an x86_64 system, although the >>> version provided is the older one. ... >> >>> The only possible "bug" is that extras could carry the latest i386 >>> package. >> >> I have dozens of x86_64 systems. On none of them did I manually install >> the i386 perl package. However, they all seem to have it installed. >> >> It seems that in many cases CentOS installs both an i386 and an x86_64 >> package when only the base package is requested, so I have thought >> nothing of it. install.log shows that the x86_64bit package was the only >> one initially installed, yum indicates that the i386 package was >> installed later (looks like during a yum update, possibly a dependency). >> >> Is this a past mistake in the repo that is only rearing its head when >> there is a mismatch between the x86_64 version in the update repo and >> the i386 version in the extra repo? Should there even exist a version in >> the extra repo? If so, it seems it should certainly be updated. > > yes it should be udpated. > I was just pointing out that the i386 version you have installed must > have come from extras, since your x86_64 system cannot see the i386 > versions available in the base+updates i386 repos that you showed in > your original post. It seemed you were wondering why these versions were > not being installed. BTW: why do you need 32bit perl? Since the package exists and you have it installed, I guess there must be use-cases... but perl being interpreted, I'm curious as to what they could be. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bug in repo affecting perl
On 02/14/12 3:59 PM, Nicolas Thierry-Mieg wrote: > BTW: why do you need 32bit perl? Since the package exists and you have > it installed, I guess there must be use-cases... but perl being > interpreted, I'm curious as to what they could be. usually in my experience, the requirement for 32 bit perl on an otherwise 64bit system stems from a perl plugin that has to be linked to a 32 bit external program which isn't available in 64bit. -- john r pierceN 37, W 122 santa cruz ca mid-left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] LDAP encryption, not sure.
Hi all, I'm setting up a local LDAP server with a pass-through authentication to another LDAP. I'm not clear about the encryption. Say the case is like this. CompB is set to have LDAP authentication. A ---> SSH ---> CompB ---> Local LDAP:389 ---> SASLAUTHD --> Global LDAP: 636 1. Password on the SSH session would be encrypted, isn't it? 2. How about when it goes to the local LDAP:389, would it be encrypted? Thank you. Fajar. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] schily tools
On Tue, Feb 14, 2012 at 12:41 PM, Joerg Schilling wrote: >> >> Gtar doesn't fail, it just requires some extra steps to accommodate some >> very unlikely circumstances. Your star runs will not work at all in very >> likely circumstances (which you conveniently avoid testing). > > Trying to understand you leads me to the assumption that you of course know > that gtar fails. As you seem to claim that there is a workaround but don't > mention it, it seems that you like other people to fail when trying to restore > incremental backups that have been made with gtar. The only thing I've ever seen fail was where the full or earlier incremental contained a directory which was subsequently replaced with a plain file with the same name that was included in a higher level incremental. The gnutar code circa 2004 didn't correctly remove the directory that should be overwritten during the incremental restore. But the error was obvious and you already know how to remove a directory. Do it, repeat the restore of the missing item and everyone is happy. But that was a long time ago, maybe things have changed. > Well, I did one test only and I know that gtar does not do what it should when > restoring incrementals. So you don't check for changes either? > If you e.g. have a 1 TB filesystem with one directory at top level and rename > that directory, you will end up with a 1 TB incremental if you use gtar. > Looking at the way gtar works, I would assume that gtar needs an intermediate > disk space of 2 TB to restore the data (if the restore works at all). > > Star will create an incremental archive of 10kB for the same change and star > does not need additional space on the restore media. Except that star won't do it at all if you want it to follow an arbitrary directory tree. >> Our definitions of 'OS and FS independent' are very different. I expect >> that to mean that I can actually change the FS and have things keep >> working. Star doesn't. And it doesn't work over nfs, on fat, ntfs, and on >> and on. > > Do you like to tell everbody that it makes no sense to believe you, or why do > you write claims that are obviously wrong? Can it follow directory trees across mount points getting incrementals right? If I'm wrong, show me the commands needed to make that work. > Star of course allows you to backup parts of a filesystem (e.g. a directory > sub-tree). And follow across mount points? >> In a word, amanda. If my backups don't fit on the tape there are no >> backups at all, and the only reason for doing incrementals at all is that >> you have to use them to make the data fit. I'm not interested in >> calculating the right mix of incremental levels on a whole bunch of >> directory trees to make each night's run fit. Amanda does that > > You again harm your credibility by writing false suggestions. > > Star is able to automatically deal with the unpredictable size of modern tapes > with HW compression, while amanda fails completely and needs to assume the > smallest possible size. This is because amanda does not make use of the > related > features of the backup utility. Star can detect the actual end of a tape in > write mode on the fly and then request a media change. I don't want a media change. No one is going to be there to change it. I want the software to compute the mix of fulls and incrementals that will fit my single daily tape. Amanda did that faithfully for many years.. >> And then there was the fact that at the time I implemented amanda, star did >> not do incremental restores anyway... > > Star implements reliable incremental restores since 7 years, so you seem to be > living in a long gone past. Yes, I believed what you said here: http://blog.gmane.org/gmane.comp.archivers.star.user/month=20040701 and haven't had any more reason to check again than you have to check gnutar. Amanda kept doing what I needed until the tape drives wore out many years later, with no more attention than swapping the tape sometime during the day. > What you like to do with gtar may require hours of manual intervention and is > still based on an unreliable basic method (as you cannot use the needed > snapshots). There is nothing that would prevent you from using snapshots with tar, but a filesystem snapshot isn't really enough to ensure that your application's view of the data is consistent anyway. Most things don't care and the ones that do have application-level ways to dump their data consistently. > You are trying to do something in an unrelibale way that can be done reliably > and fully automatically using star instead of gtar. So why do you still use > gtar? Because when I needed it, star wasn't even usable. Even if it had been able to do an incremental restore, it didn't work with amanda. >> So first we need room for filesystem snapshots, but now storing a file big >> enough to hold the equivalent of a directory listing is a problem? > > There of course is a difference between the need to st
Re: [CentOS] QEMU configuration not persistent
> After that, I'd get more drastic: > > 1. virsh shutdown $DOM. > 2. virsh dumpxml $DOM > /tmp/dom.xml > 3. virsh undefine $DOM > 4. virsh create /tmp/dom.xml > 5. virsh edit $DOM > 6. virsh start $DOM --console > > And then see if things get better. I just edit the xml files and then issue a "virsh define " to reload the newest version. (Doing this with the VM shutdown.) This has always worked ok for me. best regards, Florian La Roche ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
