Re: [CentOS] systemd and httpd
I don't have passphrases on certificates () Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 Original message From: Jack Bailey Date:2014/08/15 16:52 (GMT-06:00) To: centos@centos.org Subject: Re: [CentOS] systemd and httpd On 08/15/14 14:48, Alexander Dalloz wrote: > Am 15.08.2014 um 23:29 schrieb Jack Bailey: >> Hello, >> >> On my new CentOS 7 server httpd stops running after about two minutes or >> so. strace shows me the process is asking for a password, and failing >> to get one, times out. In reading the docs I see an option to systemd: >> --no-ask-password. Can anyone tell me where and how to set this? > You are using a passphrase protected SSL key, aren't you? > > https://wiki.apache.org/httpd/RemoveSSLCertPassPhrase I'm moving a web site from CentOS 6 to CentOS 7 where the site currently works without prompting for a password. I'll check to see if the passphase is removed from the cert. Thanks, Jack ___ 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] Webalizer not available for CentOS 7?
Hi, You can grab it from here (backported from rawhide) http://li.nux.ro/download/nux/misc/el7/x86_64/ -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - > From: "Mike McCarthy, W1NR" > To: "CentOS mailing list" > Sent: Thursday, 14 August, 2014 4:13:56 PM > Subject: [CentOS] Webalizer not available for CentOS 7? > > It seems that the Webalizer WEB statistics reporting package is no > longer available in CentOS 7. Rather than building from Sourceforge and > writing custom configuration files for it, is there an alternative? Use > the Fedora package? Another WEB analyzer? > > Thanks, > Mike > > ___ > 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] systemd and httpd
On 08/15/14 14:48, Alexander Dalloz wrote: > Am 15.08.2014 um 23:29 schrieb Jack Bailey: >> Hello, >> >> On my new CentOS 7 server httpd stops running after about two minutes or >> so. strace shows me the process is asking for a password, and failing >> to get one, times out. In reading the docs I see an option to systemd: >> --no-ask-password. Can anyone tell me where and how to set this? > You are using a passphrase protected SSL key, aren't you? > > https://wiki.apache.org/httpd/RemoveSSLCertPassPhrase I'm moving a web site from CentOS 6 to CentOS 7 where the site currently works without prompting for a password. I'll check to see if the passphase is removed from the cert. Thanks, Jack ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd and httpd
Am 15.08.2014 um 23:29 schrieb Jack Bailey: > Hello, > > On my new CentOS 7 server httpd stops running after about two minutes or > so. strace shows me the process is asking for a password, and failing > to get one, times out. In reading the docs I see an option to systemd: > --no-ask-password. Can anyone tell me where and how to set this? You are using a passphrase protected SSL key, aren't you? https://wiki.apache.org/httpd/RemoveSSLCertPassPhrase > As a workaround, I added "KillMode=none" to httpd.service, but I'd > rather use the option to just not ask for a password. > > Thanks, > Jack Alexander ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd and httpd
On Fri, Aug 15, 2014 at 4:29 PM, Jack Bailey wrote: > > On my new CentOS 7 server httpd stops running after about two minutes or > so. strace shows me the process is asking for a password, and failing > to get one, times out. In reading the docs I see an option to systemd: > --no-ask-password. Can anyone tell me where and how to set this? > > As a workaround, I added "KillMode=none" to httpd.service, but I'd > rather use the option to just not ask for a password. > I think that means you have a passphrase on the ssl certificate it is configured to use. So https probably isn't going to work the way you expect unless you remove the key encryption or supply the passphrase. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] systemd and httpd
Hello, On my new CentOS 7 server httpd stops running after about two minutes or so. strace shows me the process is asking for a password, and failing to get one, times out. In reading the docs I see an option to systemd: --no-ask-password. Can anyone tell me where and how to set this? As a workaround, I added "KillMode=none" to httpd.service, but I'd rather use the option to just not ask for a password. Thanks, Jack ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Down-grading to an "obsoleted" package
On 08/15/2014 07:45 AM, Toralf Lund wrote: > Hi, > > Does anyone know if there is a clean way to "downgrade" to the old rpm > package when it was previously replaced by another that obsolete it? > > I mean, say that I have installed some rpm "A-1.0-1.x86_64.rpm", and > along comes "B-1.0-1.x86_64.rpm", whose spec has > > Obsoletes: A > > Now, if I do "rpm -U B-1.0-1.x86_64.rpm" or "yum install > B-1.0-1.x86_64.rpm" or (if B is available through an enabled repository) > "yum update", what happens is that "A" gets removed and "B" is installed > in its place. Then I decide I want to switch back to "A". So what do I > do? I know that one answer is > > rpm -e B > rpm -U A-1.0-1.x86_64.rpm > > - but what if A and B provide facilities required by other installed > packages? I'll then have to pass "--nodeps" when removing B, but that's > something that I really want to avoid as it means loosing control over > whether all dependencies are satisfied. So is there an alternative? > > "rpm -U A-1.0-1.x86_64.rpm" alone seems to fail with file conflicts, > assuming "B" replaces some of "A"'s files. In a real scenario I tried, > there was no mention of the fact that something that was essentially a > newer version of the same package, was already installed. > > "yum upgrade A" (when the package is available on a repository) fails in > a similar manner. > > "yum localinstall A-1.0-1.x86_64.rpm" is a bit smarter - it exists with > a message like "Cannot install package A. It is obsoleted by installed > package B". > > "yum downgrade A" (via repository) says something like "No Match for > available package: A-1.0-1.x86_64.rpm". > > "yum localdowngrade A-1.0-1.x86_64.rpm" would seem to have the highest > probability of success based on the above, except that there is no such > command :-/ > > Any other ideas? > > - Toralf > You can try using 'yum shell' # yum shell > remove B > install A > run Thomas ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos7 - remove /home and expand / after install?
On Aug 15, 2014, at 11:05 AM, Les Mikesell wrote: > I did a default install and after installing some other things I > realized that a lot of space was allocated to /home as an lvm that is > never going to be used. Is it possible to remove the lvm and grow > the root (xfs) filesystem without starting over? That should be very possible For example if you have LVM for your root and home filesystems like the following /dev/Volume00/rootfs /dev/Volume00/home Do a pvscan to see how much space is available in your Volume Group /usr/sbin/pvscan If you have anything on /home you want then you can arrange to move it, tar it up, move it to the side, whatever. You can then: umount /home sed -i -e ‘/home/ d’ /etc/fstab # remove from fstab /usr/sbin/lvremove /dev/Volume00/home # remove block device, adding space back to volume group You should see the space reclaimed in the volume group /usr/sbin/pvscan At least on ext4 lvextend knows how to run resize2fs for you so you can just /usr/sbin/lvextend —size +20G —resizefs /dev/Volume00/rootfs and it will extend the logical volume then extend the filesystem. Otherwise you should be able to lvextend to the size you want then run /usr/sbin/xfs_growfs /dev/Volume00/rootfs I don’t think you have to give it any options, it’ll just grow to fill out the new size of the block device I prefer to set up new devices with filesystems of the minimal viable size and leave the rest of the space in the volume group, then it is easy to extend any particular place with more space by growing an existing filesystem or creating a new one, it is easy to have a separate filesystem for each part of an application (database, spools, logs) so that you can easily manage and monitor usage. — Mark Tinberg mtinb...@wisc.edu ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] el6 crash-trace-command vendor?
I was running a
rpm -qa --qf "%{vendor} \t\t%{name}\n" |sort|grep -v CentOS
looking for packages from other vendors installed on a machine and noticed a
curious sight:
Fujitsu Limited crash-trace-command
It appears I am not the only one who has crash-trace-command from Fujitsu
Limited
https://www.centos.org/forums/viewtopic.php?f=13&t=1081&start=0#p6688
That is a good thing right? :)
I was curious however to find it in my centos mirror, and apparently signed by
the centos crew[2].
Would one of our gentle OS maintainers be kind enough to confirm this is just
an extension of the issues in bug 5967[1]? (which I found near the end of my
web search)
Looking a little deeper it appears that there are a couple of other packages
(rome) with odd vendors in the 6.5 tree:
for i in centos/6/os/i386/Packages/*rpm; \
do rpm -q --qf "%{vendor} \t%{name}\n" -p $i; \
done |grep -v CentOS
Fujitsu Limited crash-trace-command
Red Hat, Inc. python-qpid-qmf
Red Hat, Inc. qpid-qmf
(none) rome
(none) rome-javadoc
Red Hat, Inc. ruby-qpid-qmf
[1] http://bugs.centos.org/view.php?id=5967
[2]
$ rpm -qa gpg-pubkey\*
gpg-pubkey-c105b9de-4e0fd3a3
$ for i in centos/6/os/*/Packages/crash-trace-command-*; \
do echo $i;rpm -q --qf "%{vendor} \t%{name}\n" -p $i;done
centos/6/os/i386/Packages/crash-trace-command-1.0-4.el6.i686.rpm
Fujitsu Limited crash-trace-command
centos/6/os/x86_64/Packages/crash-trace-command-1.0-4.el6.x86_64.rpm
Fujitsu Limited crash-trace-command
##Note the lack of
##"warning: centos/6/os/i386/Packages/crash-trace-command-1.0-4.el6.i686.rpm:
Header V3 RSA/SHA1 signature: NOKEY, key ID c105b9de"
## which I did get on a CentOS 5 machine doing the same check.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] Bind config question, centos 5.10
I must have something mis-configured in my bond setup. Things are working, but
I'm getting TONS of this sort of stuff in my log:
+2001:502:ad09::4#53: 1 Time(s)
network unreachable resolving 'kns1.kuwaitnet.net/A/IN':
+2001:503:231d::2:30#53: 1 Time(s)
network unreachable resolving 'kns1.kuwaitnet.net/A/IN':
+2001:503:a83e::2:30#53: 1 Time(s)
network unreachable resolving 'kns1.kuwaitnet.net//IN':
+2001:503:231d::2:30#53: 1 Time(s)
network unreachable resolving 'kns1.kuwaitnet.net//IN':
+2001:503:a83e::2:30#53: 1 Time(s)
network unreachable resolving 'kns2.kuwaitnet.net/A/IN':
+2001:503:231d::2:30#53: 1 Time(s)
network unreachable resolving 'kns2.kuwaitnet.net/A/IN':
+2001:503:a83e::2:30#53: 1 Time(s)
network unreachable resolving 'kns2.kuwaitnet.net//IN':
+2001:503:231d::2:30#53: 1 Time(s)
network unreachable resolving 'kns2.kuwaitnet.net//IN':
+2001:503:a83e::2:30#53: 1 Time(s)
network unreachable resolving 'kns3.kuwaitnet.net/A/IN':
+2001:503:231d::2:30#53: 1 Time(s)
network unreachable resolving 'kns3.kuwaitnet.net/A/IN':
+2001:503:a83e::2:30#53: 1 Time(s)
network unreachable resolving 'kns3.kuwaitnet.net//IN':
+2001:503:231d::2:30#53: 1 Time(s)
I'm not sure where to look. it may be the "any" in the named.conf lines below,
but I'm not sure.
My named.conf looks like this:
options {
listen-on port 53 { 127.0.0.1; any; };
# listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
// Those options should be used carefully because they disable port
// randomization
// query-sourceport 53;
// query-source-v6 port 53;
allow-query { localhost; any; };
allow-query-cache { localhost; any; };
# allow-query { localhost; };
# allow-query-cache { localhost; };
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
view localhost_resolver {
match-clients { localhost; any; };
match-destinations { localhost; any; };
# match-clients { localhost; };
# match-destinations { localhost; };
recursion yes;
include "/etc/named.rfc1912.zones";
};
--
ACCEL Services, Inc.| Specialists in Gravity, Magnetics | (713)993-0671 ph.
| and Integrated Interpretation | (713)993-0608 fax
448 W. 19th St. #325|Since 1992 | (713)306-5794 cell
Houston, TX, 77008 | Chuck Campbell | campb...@accelinc.com
| President & Senior Geoscientist |
"Integration means more than having all the maps at the same scale!"
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] Centos7 - remove /home and expand / after install?
I did a default install and after installing some other things I realized that a lot of space was allocated to /home as an lvm that is never going to be used. Is it possible to remove the lvm and grow the root (xfs) filesystem without starting over? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux vs. logwatch and virsh
On 08/14/2014 11:02 AM, Bill Gee wrote: > Hello everyone - > > I am stumped ... Does anyone have suggestions on how to proceed? Is there a > way > to get what I want? > > The environment: CentOS 7.0 with latest patches. > > The goal: I want logwatch to include a report on the status of kvm virtual > computers. > > The problem: When run from anacron, SELinux denies permission for the virsh > utility. > Here is a portion of the logwatch output: > > - KVM libvirt status report Begin > > > Date Range: yesterday > /etc/logwatch/scripts/services/libvirt: line 15: /usr/bin/virsh: Permission > denied > > -- KVM libvirt status report End > - > > If I "run-parts /etc/cron.daily" from a root console, it all works. Same if > I run "logwatch" > from a root console. > > I set SELinux to permissive and that allows virsh to run. Therefore I know > it is > something to do with SELinux. > > The logwatch script is: > > #Lots of comments > /usr/bin/virsh list --all > > I see the selinux security context of virsh is > > system_u:object_r:virsh_exec_t:s0 > > while logwatch.pl runs as > > system_u:object_r:logwatch_exec_t:s0 > > As I understand it, selinux does not permit having multiple type settings for > a file. Any > file can have exactly one type setting. > > I ran this command hoping it would add another type to the virsh program. > > semanage fcontext -a -t logwatch_exec_t /usr/bin/virsh > > semanage fcontext --list /usr/bin/virsh | grep virsh > /usr/bin/virsh all files > system_u:object_r:logwatch_exec_t:s0 > /usr/bin/virsh regular file > system_u:object_r:virsh_exec_t:s0 > /usr/sbin/xl regular file > system_u:object_r:virsh_exec_t:s0 > /usr/sbin/xm regular file > system_u:object_r:virsh_exec_t:s0 > > Semanage did add the new type, but that did not fix the problem. Virsh still > gets > "permission denied" when logwatch tries to run it. > > Thanks - Bill Gee > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos BTW if you think this is something we should do in general in such a way as logwatch can only look at the content in Read Only mode, then we might want it to become default. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux vs. logwatch and virsh
On 08/14/2014 11:02 AM, Bill Gee wrote: > Hello everyone - > > I am stumped ... Does anyone have suggestions on how to proceed? Is there a > way > to get what I want? > > The environment: CentOS 7.0 with latest patches. > > The goal: I want logwatch to include a report on the status of kvm virtual > computers. > > The problem: When run from anacron, SELinux denies permission for the virsh > utility. > Here is a portion of the logwatch output: > > - KVM libvirt status report Begin > > > Date Range: yesterday > /etc/logwatch/scripts/services/libvirt: line 15: /usr/bin/virsh: Permission > denied > > -- KVM libvirt status report End > - > > If I "run-parts /etc/cron.daily" from a root console, it all works. Same if > I run "logwatch" > from a root console. > > I set SELinux to permissive and that allows virsh to run. Therefore I know > it is > something to do with SELinux. > > The logwatch script is: > > #Lots of comments > /usr/bin/virsh list --all > > I see the selinux security context of virsh is > > system_u:object_r:virsh_exec_t:s0 > > while logwatch.pl runs as > > system_u:object_r:logwatch_exec_t:s0 > > As I understand it, selinux does not permit having multiple type settings for > a file. Any > file can have exactly one type setting. > > I ran this command hoping it would add another type to the virsh program. > > semanage fcontext -a -t logwatch_exec_t /usr/bin/virsh > > semanage fcontext --list /usr/bin/virsh | grep virsh > /usr/bin/virsh all files > system_u:object_r:logwatch_exec_t:s0 > /usr/bin/virsh regular file > system_u:object_r:virsh_exec_t:s0 > /usr/sbin/xl regular file > system_u:object_r:virsh_exec_t:s0 > /usr/sbin/xm regular file > system_u:object_r:virsh_exec_t:s0 > > Semanage did add the new type, but that did not fix the problem. Virsh still > gets > "permission denied" when logwatch tries to run it. > > Thanks - Bill Gee > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos What AVC messages are you seeing? ausearch -m avc -ts recent. I would put the machine in permissive mode, run your tests and then add the allow rules using audit2allow -M mylogwatch ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Down-grading to an "obsoleted" package
Hi, Does anyone know if there is a clean way to "downgrade" to the old rpm package when it was previously replaced by another that obsolete it? I mean, say that I have installed some rpm "A-1.0-1.x86_64.rpm", and along comes "B-1.0-1.x86_64.rpm", whose spec has Obsoletes: A Now, if I do "rpm -U B-1.0-1.x86_64.rpm" or "yum install B-1.0-1.x86_64.rpm" or (if B is available through an enabled repository) "yum update", what happens is that "A" gets removed and "B" is installed in its place. Then I decide I want to switch back to "A". So what do I do? I know that one answer is rpm -e B rpm -U A-1.0-1.x86_64.rpm - but what if A and B provide facilities required by other installed packages? I'll then have to pass "--nodeps" when removing B, but that's something that I really want to avoid as it means loosing control over whether all dependencies are satisfied. So is there an alternative? "rpm -U A-1.0-1.x86_64.rpm" alone seems to fail with file conflicts, assuming "B" replaces some of "A"'s files. In a real scenario I tried, there was no mention of the fact that something that was essentially a newer version of the same package, was already installed. "yum upgrade A" (when the package is available on a repository) fails in a similar manner. "yum localinstall A-1.0-1.x86_64.rpm" is a bit smarter - it exists with a message like "Cannot install package A. It is obsoleted by installed package B". "yum downgrade A" (via repository) says something like "No Match for available package: A-1.0-1.x86_64.rpm". "yum localdowngrade A-1.0-1.x86_64.rpm" would seem to have the highest probability of success based on the above, except that there is no such command :-/ Any other ideas? - Toralf This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 as gateway - UDP performance is busted/awful?
On Fri, 15 Aug 2014 09:19:29 -0400 David Both wrote: > I hope this helps. Nah, all the forwarding rules were in place. They all worked before I switched to centos7, and they all worked after I booted the fedora kernel. No sysctl or iptables changes were made when switching from centos to fedora kernel, yet the forwarding started working after booting fedora. I suspect if I backed up to the kernel centos 6.5 uses that would work as well. I betcha someone has a < that should be a <= somewhere in an MTU size check in the centos7 kernel :-). ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 as gateway - UDP performance is busted/awful?
Nope. The kernel is not busted. You just need to add a few rules to your firewall in order to tell it to forward the packets appropriately. While you do need "net.ipv4.ip_forward = 1" line in /etc/sysctl.conf, and you also need to set /proc/sys/net/ipv4/ip_forward to 1 if you have not rebooted after setting the line in sysctl.conf, firewall rules are required to make it work. Unfortunately the specific firewall rules you require will depend upon the release level of the distribution you use. IPTables has changed a bit over the years and so the specific rules and their syntax has changed as well. Here is what I use now with CentOS 6.5+ on my own network. # Generated by iptables-save v1.4.7 on Fri Aug 15 09:11:28 2014 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [825:47118] :fail2ban-SSH - [0:0] -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i eth+ -j ACCEPT -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -p icmp -j ACCEPT -A FORWARD -i lo -j ACCEPT -A FORWARD -i eth0 -j ACCEPT -A FORWARD -i eth1 -j ACCEPT -A FORWARD -j REJECT --reject-with icmp-host-prohibited -A fail2ban-SSH -j RETURN COMMIT # Completed on Fri Aug 15 09:11:28 2014 # Generated by iptables-save v1.4.7 on Fri Aug 15 09:11:28 2014 *nat :PREROUTING ACCEPT [80965:6238336] :POSTROUTING ACCEPT [37811:2251658] :OUTPUT ACCEPT [838:63592] -A PREROUTING -d 24.199.159.56/29 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.0.53:80 -A PREROUTING -d 24.199.159.56/29 -p tcp -m tcp --dport 25 -j DNAT --to-destination 192.168.0.53:25 -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE COMMIT # Completed on Fri Aug 15 09:11:28 2014 The FORWARD rules in the filter table allow forwarding from your internal networks on eth0 and eth1 to the outside world. The Destination NATing PREROUTING rules allow incoming packets for SMTP and HTTP to be routed to the appropriate server on my inside network. I hope this helps. On 08/15/2014 07:50 AM, Tom Horsley wrote: > I think I have my answer: The kernel is busted (or something > isn't loaded that I need, but don't know about :-). > > I copied my Fedora 20 desktop 3.15.8-200.fc20.x86_64 kernel > and /lib/module files to the centos7 KVM host, rebuilt > grub.cfg, and rebooted into the 3.15.8-200 kernel, and > with no other changes the UDP packet forwarding is now working > perfectly. > > I guess it is time to make yet another bugzilla account > and submit a bug... > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos -- * "I'd put my money on the sun and solar energy. What a source of power! I hope we don't have to wait until oil and coal run out before we tackle that." - Thomas Edison, in conversation with Henry Ford and Harvey Firestone, 1931 * David P. Both * This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately. -- * David P. Both, RHCE Millennium Technology Consulting LLC 919-389-8678 db...@millennium-technology.com www.millennium-technology.com www.databook.bz - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 as gateway - UDP performance is busted/awful?
> It is much easier if you use ELRepo's kernel-ml > (http://elrepo.org/tiki/kernel-ml). Does look like a better long term solution, fedora was just a hack for testing :-). > > I guess it is time to make yet another bugzilla account > > and submit a bug... > > Yes, good idea. And here it is: http://bugs.centos.org/view.php?id=7505 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 as gateway - UDP performance is busted/awful?
On Fri, Aug 15, 2014 at 4:50 AM, Tom Horsley wrote: > I think I have my answer: The kernel is busted (or something > isn't loaded that I need, but don't know about :-). > > I copied my Fedora 20 desktop 3.15.8-200.fc20.x86_64 kernel > and /lib/module files to the centos7 KVM host, rebuilt > grub.cfg, and rebooted into the 3.15.8-200 kernel, and > with no other changes the UDP packet forwarding is now working > perfectly. It is much easier if you use ELRepo's kernel-ml (http://elrepo.org/tiki/kernel-ml). > I guess it is time to make yet another bugzilla account > and submit a bug... Yes, good idea. Akemi ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 114, Issue 9
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. CEBA-2014:1056 CentOS 6 glibc Update (Johnny Hughes)
2. CEBA-2014:1057 CentOS 7 dhcp BugFix Update (Johnny Hughes)
3. CEBA-2014:1058 CentOS 7 lorax BugFix Update (Johnny Hughes)
--
Message: 1
Date: Thu, 14 Aug 2014 12:42:05 +
From: Johnny Hughes
Subject: [CentOS-announce] CEBA-2014:1056 CentOS 6 glibc Update
To: centos-annou...@centos.org
Message-ID: <20140814124205.ga17...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2014:1056
Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-1056.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
0aa321759a9c2600d535e439f2d6f27c40414100327f3f55a79361fce806fd0a
glibc-2.12-1.132.el6_5.3.i686.rpm
542994b792277a86f69f56169f6989ae4df3efad1722b6d8939269213dcff8cf
glibc-common-2.12-1.132.el6_5.3.i686.rpm
41a52d240c8dbb9c3153cee50c03b763e8511a4cc43c94a5f7015c742c577f17
glibc-devel-2.12-1.132.el6_5.3.i686.rpm
7e8a8ffc38bb93ca282ee7f83b1a123ea47ac40c3b8457fa0bd1d38b9087d70e
glibc-headers-2.12-1.132.el6_5.3.i686.rpm
f1cdbf4132208c8dcfd92f76c6a1395580a4d9242561af95fb7524c7adbd3c56
glibc-static-2.12-1.132.el6_5.3.i686.rpm
948ed1bd86537cab571ae228cb4a2b40de35f1ced8e3bbb9af85c1c43b61d080
glibc-utils-2.12-1.132.el6_5.3.i686.rpm
393daaa3967f0451af17c6d0dd53614bffb84057f9570361e4edbec11b4da352
nscd-2.12-1.132.el6_5.3.i686.rpm
x86_64:
0aa321759a9c2600d535e439f2d6f27c40414100327f3f55a79361fce806fd0a
glibc-2.12-1.132.el6_5.3.i686.rpm
f4849c174991014b0c68fbdd44e88e1ab2d1387f940df29910a42bd24f672c29
glibc-2.12-1.132.el6_5.3.x86_64.rpm
7c7086d89be068c7b0ccb0421e86a16804702af543576ed7d63ed47d3c2302c7
glibc-common-2.12-1.132.el6_5.3.x86_64.rpm
41a52d240c8dbb9c3153cee50c03b763e8511a4cc43c94a5f7015c742c577f17
glibc-devel-2.12-1.132.el6_5.3.i686.rpm
9d6d02d5d540c987f2ba40c5fcda2f249f5147d02ea4fd726b5499cad0c66e04
glibc-devel-2.12-1.132.el6_5.3.x86_64.rpm
ffbb30250608e5d01056e3598a7fe4bd37f3680261b005ce76965ab56f2767b5
glibc-headers-2.12-1.132.el6_5.3.x86_64.rpm
f1cdbf4132208c8dcfd92f76c6a1395580a4d9242561af95fb7524c7adbd3c56
glibc-static-2.12-1.132.el6_5.3.i686.rpm
7ee821b2f6382ef22cd7192665c67bfe7b2c44d11d2c982cca118a190200479d
glibc-static-2.12-1.132.el6_5.3.x86_64.rpm
3958b8a205ae7df1f6cf6decbe70e5c5fad759d8d41b627bb3404674f20d51ed
glibc-utils-2.12-1.132.el6_5.3.x86_64.rpm
d71932c528b909552291356796420c455bcfb6122dbd21058bdc716fe8ddebf5
nscd-2.12-1.132.el6_5.3.x86_64.rpm
Source:
92a4bad8ed4070c35c039c2e04ad72b929f934fdbaabc6e7033ae88876a52e67
glibc-2.12-1.132.el6_5.3.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
--
Message: 2
Date: Thu, 14 Aug 2014 13:39:26 +
From: Johnny Hughes
Subject: [CentOS-announce] CEBA-2014:1057 CentOS 7 dhcp BugFix Update
To: centos-annou...@centos.org
Message-ID: <20140814133926.ga40...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2014:1057
Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-1057.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
a4084c7b74bdaa8da08fc6956c251f3e693948a2530bc2b181a65cf961480c8d
dhclient-4.2.5-27.el7.centos.1.i686.rpm
df3c78924f70cc4e720f0342c5d13b629672ce4cf14dc50ce65204b383c45de3
dhclient-4.2.5-27.el7.centos.1.x86_64.rpm
42f9f68872055407c2955d0fa534f7cf624a5de7eee4152e80ca944e467a65d3
dhcp-4.2.5-27.el7.centos.1.i686.rpm
4ccf970bb20cfaf202675f1941230e87c9f67e4aa838da84384e0add1a101ec1
dhcp-4.2.5-27.el7.centos.1.x86_64.rpm
b5d01e7cc3f9a6d9f469765a98f625ed2178ea37ab979bf17324821ddb543b0d
dhcp-common-4.2.5-27.el7.centos.1.i686.rpm
1bb58312cc303b1bc05ea03e4b456d8b4d381b7f028f590e396bfd8d7a310bae
dhcp-common-4.2.5-27.el7.centos.1.x86_64.rpm
c2cc9b5e0f787338ce25190e2722a2af0c761f21dc0d8f70527527bef192a168
dhcp-devel-4.2.5-27.el7.centos.1.i686.rpm
39a99e9a696d7884f68a54e7c8e34f3b45d68b8031f0a44c73b0a6c2e575d64f
dhcp-devel-4.2.5-27.el7.centos.1.x86_64.rpm
fe5d215ed35928d293326c75f2f2855632da787cefa3e31562afb842e13ca6d7
dhcp-libs-4.2.5-27.el7.centos.1.i686.rpm
28b415a65abf25b741c480260c3c54ce131e5120a477472d659c5bf490216ed7
dhcp-libs-4.2.5-27.el7.centos.1.x86_64.rpm
Source:
ebe241d0850b9e
Re: [CentOS] Centos 7 as gateway - UDP performance is busted/awful?
I think I have my answer: The kernel is busted (or something isn't loaded that I need, but don't know about :-). I copied my Fedora 20 desktop 3.15.8-200.fc20.x86_64 kernel and /lib/module files to the centos7 KVM host, rebuilt grub.cfg, and rebooted into the 3.15.8-200 kernel, and with no other changes the UDP packet forwarding is now working perfectly. I guess it is time to make yet another bugzilla account and submit a bug... ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 as gateway - UDP performance is busted/awful?
In article <20140814141900.777d6f0c@tomh>, Tom Horsley wrote: > > If you look inside the ICMP packet in wireshark, it will tell you > > who sent it and what MTU they said was acceptable. > > Well, I'm definitely drowning in network confusion here :-). > > Everyone's MTU is the default 1500, I checked all systems in > the path. > > The wireshark display says 1516 in the Length column for the > NFS packet that always shows up before the ICMP errors. If I > expand the "IP V4" line in the packet, it says "Total Length: 1500" > for that READDIRPLUS Reply which says 1516 for the capture > length. It also has the "Don't fragment" flag set. > > It looks like the 16 byte extra is confusing it, but I have no > idea why that is different than the IPv4 length info. The 1516 is the total length of the ethernet frame, and is normal for a 1500 MTU. The 16 bytes is the link-layer header. When looking at the ICMP Frag-needed packet in Wireshark, look particularly at (a) its source and destination addresses, (b) the "MTU of next hop" field (in expansion of ICMP), and (c) the source and destination addresses of the packet it was complaining about. Here's an example from one of my recent traces: Frame 235: 72 bytes on wire (576 bits), 72 bytes captured (576 bits) Linux cooked capture Internet Protocol Version 4, Src: 10.30.0.245 (10.30.0.245), Dst: 172.22.21.48 (172.22.21.48) (a) ^^ Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 4 (Fragmentation needed) Checksum: 0x81df [correct] MTU of next hop: 1476 (b) Internet Protocol Version 4, Src: 172.22.21.48 (172.22.21.48), Dst: 172.27.60.31 (172.27.60.31) (c) ^^ ^^ Transmission Control Protocol, Src Port: ssh (22), Dst Port: 56199 (56199) Cheers Tony -- Tony Mountifield Work: t...@softins.co.uk - http://www.softins.co.uk Play: t...@mountifield.org - http://tony.mountifield.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
