[CentOS] Bash package for CentOS5
Hi! I have noticed, that our mirror has this package bash-3.2-33.el5_11.4.x86_64.rpm, but a lot of other mirror still have bash-3.2-33.el5_10.4.x86_64.rpm. Since bash-3.2-33.el5_11.4.x86_64.rpm was issued on 26-Sep-2014 04:28, could this be the product of slower mirror update cycles? Regards, Mitja -- -- Mitja Mihelič ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia tel: +386 1 479 8877, fax: +386 1 479 88 78 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SSSD and usermod
Hi Dimitar! FreeIPA might be worth a look. We already have a user management system that currently manages passwd/shadow. The idea was to migrate passwd/shadow info to 389DS so we could distribute the users across multiple servers. Perhaps our management system could use FreeIPA's tools for user management. I could not find find the attachment in your last email, could you please send it again? Do you perhaps have experience in managing a SSSD-389DS system with 70k users and about 500 queries per second to SSSD? Regards, Mitja -- Mitja Mihelič ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia tel: +386 1 479 8877, fax: +386 1 479 88 78 On 07. 01. 2014 21:27, Dimitar Georgievski wrote: Hi Mitja, From the description of the problem it seems that the usermod - SSSD integration is not working. 389DS just stores the user information but SSSD is not enforcing the policy, and usermod fails because the user info is not stored locally. I think you should consider using FreeIPA instead of just 389DS, because with it you would be able to manage centrally user policies (sudo, host access rules, account expiration etc). With this you would be able to enforce a lock of a user account on a particular host or group of hosts. FreeIPA would just give you the user friendly tools (Web UI and command line) to manage the user accounts and their policies. 389DS would still be storing and providing the information about these resources. You should also try posting this question on the freeipa mailing list. It also covers the usage of the SSSD client. You could get answers to your questions directly from the developers and RH engineers. If it's of any help I've attached a sample of SSSD configuration used in our environment. Thanks Dimitar On Tue, Jan 7, 2014 at 7:57 AM, Mitja Mihelič mitja.mihe...@arnes.siwrote: Hi Dimitar! We only want to SSSD with 389DS instead of the local passwd/shadow files. We do not want to go full IPA for this server. Setting up SSSD with authconfig automatically set up PAM and /etc/nsswitch.conf. SSSD will only be used for these (nsswitch.conf): passwd:files sss shadow:files sss services: files sss I have also attached our sssd.conf. Currently getent and id cmdline tools work as expected by getting user info from SSSD which in turn gets it from 389DS/LDAP. SSH also works. We are starting to lean toward the possibility, that usermod and its sibling utils from shadow-utils do not support SSSD as fully as we were expecting them to. Is this the case and can any other cmdline user administration tools be used to lock users? I know there is the possibility of making our own tools for this, but still... Regards, Mitja -- Mitja Mihelič ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia tel: +386 1 479 8877, fax: +386 1 479 88 78 On 06. 01. 2014 16:02, Dimitar Georgievski wrote: Hi MItja, it looks like you are trying to integrate SSSD with FreeIPA. I think the following presentation will help you review the SSSD configuration even if you are trying to use 389DS independently: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf Check the page titled Example configuration - SSSD with FreeIPA server. SSSD has to be configured to talk to LDAP server. Check also the settings in /etc/nsswitch.conf. You might need to modify it to enable SSSD integration with other services. This example comes from a host that is using SSSD for SSH authentication and sudo integration with a FreeIPA server: passwd: files sss shadow: files sss group: files sss sudoers:files sss Dimitar On Fri, Jan 3, 2014 at 10:17 AM, Mitja Mihelič mitja.mihe...@arnes.si wrote: Hi! How to get usermod working with SSSD/389DS ? We have SSSD set up on our server and it uses 389DS. SSSD was enabled with the following command: authconfig --enablesssd --enablesssdauth --ldapbasedn=dc=example,dc=com --enableshadow --enablemkhomedir --enablelocauthorize --update Running for example usermod -L username returns: usermod: user 'username' does not exist in /etc/passwd Each time usermod is executed there is a query logged in 389DS, so SSSD does pass the request to 389DS. Strace (attached) of usermod shows that it gets at least gecos back from SSSD and that it checked the /var/lib/sss/mc/passwd file which contains: username Name Lastname /home/username /bin/bash Soon after that it starts to open /etc/shadow and /etc/passwd. What are we missing? Any insight would be appreciated. Regards, Mitja -- -- Mitja Mihelič ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia tel: +386 1 479 8877, fax: +386 1 479 88 78 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http
Re: [CentOS] SSSD and usermod
Hi Dimitar! We only want to SSSD with 389DS instead of the local passwd/shadow files. We do not want to go full IPA for this server. Setting up SSSD with authconfig automatically set up PAM and /etc/nsswitch.conf. SSSD will only be used for these (nsswitch.conf): passwd:files sss shadow:files sss services: files sss I have also attached our sssd.conf. Currently getent and id cmdline tools work as expected by getting user info from SSSD which in turn gets it from 389DS/LDAP. SSH also works. We are starting to lean toward the possibility, that usermod and its sibling utils from shadow-utils do not support SSSD as fully as we were expecting them to. Is this the case and can any other cmdline user administration tools be used to lock users? I know there is the possibility of making our own tools for this, but still... Regards, Mitja -- Mitja Mihelič ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia tel: +386 1 479 8877, fax: +386 1 479 88 78 On 06. 01. 2014 16:02, Dimitar Georgievski wrote: Hi MItja, it looks like you are trying to integrate SSSD with FreeIPA. I think the following presentation will help you review the SSSD configuration even if you are trying to use 389DS independently: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf Check the page titled Example configuration - SSSD with FreeIPA server. SSSD has to be configured to talk to LDAP server. Check also the settings in /etc/nsswitch.conf. You might need to modify it to enable SSSD integration with other services. This example comes from a host that is using SSSD for SSH authentication and sudo integration with a FreeIPA server: passwd: files sss shadow: files sss group: files sss sudoers:files sss Dimitar On Fri, Jan 3, 2014 at 10:17 AM, Mitja Mihelič mitja.mihe...@arnes.siwrote: Hi! How to get usermod working with SSSD/389DS ? We have SSSD set up on our server and it uses 389DS. SSSD was enabled with the following command: authconfig --enablesssd --enablesssdauth --ldapbasedn=dc=example,dc=com --enableshadow --enablemkhomedir --enablelocauthorize --update Running for example usermod -L username returns: usermod: user 'username' does not exist in /etc/passwd Each time usermod is executed there is a query logged in 389DS, so SSSD does pass the request to 389DS. Strace (attached) of usermod shows that it gets at least gecos back from SSSD and that it checked the /var/lib/sss/mc/passwd file which contains: username Name Lastname /home/username /bin/bash Soon after that it starts to open /etc/shadow and /etc/passwd. What are we missing? Any insight would be appreciated. Regards, Mitja -- -- Mitja Mihelič ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia tel: +386 1 479 8877, fax: +386 1 479 88 78 ___ 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 [domain/default] ldap_tls_reqcert = demand ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = dc=users,dc=company,dc=tld ldap_group_member = uniquemember id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://ldap.company.si ldap_tls_cacertdir = /etc/openldap/cacerts enumerate = false min_id = 1 ldap_default_bind_dn = cn=SSSDUSER,ou=system,dc=company,dc=tld ldap_default_authtok_type = obfuscated_password ldap_default_authtok = PASSWORD_HERE ldap_disable_paging = true ldap_enumeration_refresh_timeout = 300 [sssd] services = nss, pam config_file_version = 2 domains = default [nss] filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd memcache_timeout = 1200 enum_cache_timeout = 400 entry_negative_timeout = 5 debug_level = 0x0400 [pam] reconnection_retries = 3 offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5 debug_level = 0x0400 [sudo] [autofs] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] SSSD and usermod
Hi!
How to get usermod working with SSSD/389DS ?
We have SSSD set up on our server and it uses 389DS.
SSSD was enabled with the following command:
authconfig --enablesssd --enablesssdauth --ldapbasedn=dc=example,dc=com
--enableshadow --enablemkhomedir --enablelocauthorize --update
Running for example usermod -L username returns:
usermod: user 'username' does not exist in /etc/passwd
Each time usermod is executed there is a query logged in 389DS, so SSSD
does pass the request to 389DS.
Strace (attached) of usermod shows that it gets at least gecos back from
SSSD and that it checked the /var/lib/sss/mc/passwd file which contains:
username
Name Lastname
/home/username
/bin/bash
Soon after that it starts to open /etc/shadow and /etc/passwd.
What are we missing?
Any insight would be appreciated.
Regards, Mitja
--
--
Mitja Mihelič
ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia
tel: +386 1 479 8877, fax: +386 1 479 88 78
execve(/usr/sbin/usermod, [usermod, -L, username], [/* 32 vars */]) = 0
brk(0) = 0x7f96c186
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f96bfe44000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=23522, ...}) = 0
mmap(NULL, 23522, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f96bfe3e000
close(3)= 0
open(/lib64/libaudit.so.1, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\260%\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=113096, ...}) = 0
mmap(NULL, 2208304, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f96bfa0a000
mprotect(0x7f96bfa21000, 2093056, PROT_NONE) = 0
mmap(0x7f96bfc2, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x7f96bfc2
close(3)= 0
open(/lib64/libselinux.so.1, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0PX\0\0\0\0\0\0..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=122040, ...}) = 0
mmap(NULL, 2221912, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f96bf7eb000
mprotect(0x7f96bf808000, 2093056, PROT_NONE) = 0
mmap(0x7f96bfa07000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c000) = 0x7f96bfa07000
mmap(0x7f96bfa09000, 1880, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f96bfa09000
close(3)= 0
open(/lib64/libacl.so.1, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\200\36\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=31280, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f96bfe3d000
mmap(NULL, 2126416, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f96bf5e3000
mprotect(0x7f96bf5ea000, 2093056, PROT_NONE) = 0
mmap(0x7f96bf7e9000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f96bf7e9000
close(3)= 0
open(/lib64/libc.so.6, O_RDONLY) = 3
read(3, \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\\356\1\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1921216, ...}) = 0
mmap(NULL, 3750152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f96bf24f000
mprotect(0x7f96bf3da000, 2093056, PROT_NONE) = 0
mmap(0x7f96bf5d9000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18a000) = 0x7f96bf5d9000
mmap(0x7f96bf5de000, 18696, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f96bf5de000
close(3)= 0
open(/lib64/libdl.so.2, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\340\r\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=19536, ...}) = 0
mmap(NULL, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f96bf04b000
mprotect(0x7f96bf04d000, 2097152, PROT_NONE) = 0
mmap(0x7f96bf24d000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f96bf24d000
close(3)= 0
open(/lib64/libattr.so.1, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\200\23\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=18712, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f96bfe3c000
mmap(NULL, 2113888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f96bee46000
mprotect(0x7f96bee4a000, 2093056, PROT_NONE) = 0
mmap(0x7f96bf049000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f96bf049000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f96bfe3b000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f96bfe39000
arch_prctl
[CentOS] SSSD with 389DS
Hi! We are setting up an environment with two 389DS configured as master-consumer. The DIT holds about 70.000 user records. A couple of other machines running SSSD will be using the 389DS setup for all user info lookups that would normally go to passwd/shadow. There are also other applications that will be querying the 389DS for various other user data. All servers are running CentOS6. In total I would estimate that SSSD would be handling about 400 queries per second. How should I configure SSSD to get the most out of it? Cache refreshes, (negative) timeouts, expirations, enumerations? Regards, Mitja -- -- Mitja Mihelič ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia tel: +386 1 479 8877, fax: +386 1 479 88 78 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Ping time resolution
Hi! We have encountered a rather weird problem on a machine that we use for our network latency check (smokeping with fping). For an hour (or so) after boot it reports the ping time with a microsecond accuracy (ad it should). Then the millisecond accuracy starts. We have yet to identify the cause and the logs currently do not show anything. Please find an example of a good and a bad result below. Regards, Mitja When it works: (microsecond accuracy): [r...@server ~]# ping test.example.net PING test.example.net (123.1.2.3) 56(84) bytes of data. 64 bytes from test.example.net (123.1.2.3): icmp_seq=1 ttl=62 time=0.562 ms 64 bytes from test.example.net (123.1.2.3): icmp_seq=2 ttl=62 time=0.452 ms 64 bytes from test.example.net (123.1.2.3): icmp_seq=3 ttl=62 time=0.579 ms --- test.example.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.452/0.531/0.579/0.056 ms And when it does not (millisecond accuracy): [r...@server ~]# ping test.example.net PING test.example.net (123.1.2.3) 56(84) bytes of data. 64 bytes from test.example.net (123.1.2.3): icmp_seq=1 ttl=62 time=1.99 ms 64 bytes from test.example.net (123.1.2.3): icmp_seq=2 ttl=62 time=0.999 ms 64 bytes from test.example.net (123.1.2.3): icmp_seq=3 ttl=62 time=0.000 ms 64 bytes from test.example.net (123.1.2.3): icmp_seq=4 ttl=62 time=0.000 ms 64 bytes from test.example.net (123.1.2.3): icmp_seq=5 ttl=62 time=0.000 ms --- test.example.net ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.000/0.599/1.999/0.800 ms ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Routing local generted packets with fwmark
On 10/15/2010 08:48 AM, C. L. Martinez wrote: On Wed, Oct 13, 2010 at 11:22 AM, C. L. Martinez carlopm...@gmail.com mailto:carlopm...@gmail.com wrote: Hi all, I need to route local generated packages depending on which tcp or udp service I need to use. To accomplish this I have configured two routing tables: [r...@lothlorien ~]# ip ru ls 0: from all lookup 255 32762: from all fwmark 0x2 lookup FirstLan 32763: from all fwmark 0x1 lookup SecondLan 32764: from 172.25.80.10 lookup SecondLan 32765: from 172.25.70.18 lookup FirstLan 32766: from all lookup main 32767: from all lookup default My routing tables: [r...@lothlorien net]# ip ro show table FirstLan 172.25.70.16/28 http://172.25.70.16/28 dev eth1 proto kernel scope link src 172.25.70.18 default via 172.25.70.30 dev eth1 [r...@lothlorien net]# ip ro show table SecondLan 172.25.80.0/24 http://172.25.80.0/24 dev eth1 proto kernel scope link src 172.25.80.10 default via 172.25.80.1 dev eth2 And my iptables rule is: iptables -t mangle -A OUTPUT -p udp --dport 53 -j MARK --set-mark 1 I had a similar problem, so I wrote the mark as 0x1 : iptables -t mangle -A OUTPUT -p udp --dport 53 -j MARK --set-mark 0x1 -- MM ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Routing of outgoing packets
On 09/30/2010 05:02 PM, John Doe wrote: From: Mitja Miheličmitja.mihe...@arnes.si I am trying to use hping to chek the latency of our network. Somehow things are not going to plan and I thought someone might be able to shed some light on the subject. Here is the setup: (the IP addresses gvien here are fake, but they do represent the correct state of the networking setup) vlan interface IP mask V2eth0 192.168.20.2032 V4eth1 172.16.4.4032 V6eth2 172.16.6.6032 The default route is set to eth1. The idea is to use eth2 for pinging only, the other two interfaces are used by another service and management access. Could you show the ifconfig and route outputs...? JD The Centos version is 5.5. This is the kernel we are using (http://rpms.mcnc.org/web100/el5/distro-compat/i386/): 2.6.18-164.15.1.el5.web100PAE #1 SMP Mon May 17 17:01:51 EDT 2010 i686 athlon i386 GNU/Linux The IP addresses are presented as private addresses, netmasks are real. Here is the ifconfig output: [r...@server ~]# ifconfig eth0 Link encap:Ethernet HWaddr 00:16:35:82:45:A0 inet addr:192.168.254.236 Bcast:192.168.254.239 Mask:255.255.255.240 inet6 addr: fe80::216:35ff:fe82:45a0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:139602 errors:0 dropped:0 overruns:0 frame:0 TX packets:58914 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:211203420 (201.4 MiB) TX bytes:4285647 (4.0 MiB) Interrupt:186 Memory:dc00-dc012800 eth1 Link encap:Ethernet HWaddr 00:16:35:82:45:A2 inet addr:192.168.254.244 Bcast:192.168.254.247 Mask:255.255.255.248 inet6 addr: fe80::216:35ff:fe82:45a2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:15 errors:0 dropped:0 overruns:0 frame:0 TX packets:14 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1130 (1.1 KiB) TX bytes:1116 (1.0 KiB) Interrupt:194 Memory:da00-da012800 eth2 Link encap:Ethernet HWaddr 00:15:17:C5:84:4D inet addr:192.168.254.18 Bcast:192.168.254.23 Mask:255.255.255.248 inet6 addr: fe80::215:17ff:fec5:844d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:29 errors:0 dropped:0 overruns:0 frame:0 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2280 (2.2 KiB) TX bytes:1236 (1.2 KiB) Memory:dfde-dfe0 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:21 errors:0 dropped:0 overruns:0 frame:0 TX packets:21 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4240 (4.1 KiB) TX bytes:4240 (4.1 KiB) And the route command output: [r...@server ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.18.122 192.168.254.225 255.255.255.255 UGH 0 0 0 eth0 192.168.254.16 0.0.0.0 255.255.255.248 U 0 0 0 eth2 192.168.254.240 0.0.0.0 255.255.255.248 U 0 0 0 eth1 192.168.18.160 192.168.254.225 255.255.255.240 UG0 0 0 eth0 192.168.254.224 0.0.0.0 255.255.255.240 U 0 0 0 eth0 192.168.1.64 192.168.254.225 255.255.255.192 UG0 0 0 eth0 192.168.1.128192.168.254.225 255.255.255.128 UG0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2 0.0.0.0 192.168.254.241 0.0.0.0 UG0 0 0 eth1 -- Mitja ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Routing of outgoing packets
Hi! I am trying to use hping to chek the latency of our network. Somehow things are not going to plan and I thought someone might be able to shed some light on the subject. Here is the setup: (the IP addresses gvien here are fake, but they do represent the correct state of the networking setup) vlan interface IP mask V2eth0 192.168.20.2032 V4eth1 172.16.4.4032 V6eth2 172.16.6.6032 The default route is set to eth1. The idea is to use eth2 for pinging only, the other two interfaces are used by another service and management access. If I do: ping -c 2 -I eth2 74.125.39.147 or fping -c 2 -I eth2 74.125.39.147 It binds to eth2 and sends its ICMP probes via that interface with the IP on that interface. If I do: hping3 -1 -c 2 -I eth2 74.125.39.147 -VD or [r...@server ~]# hping3 -c 2 -I eth2 74.125.39.147 -VD DEBUG: if lo: Don't Match (but seems to be UP) DEBUG: if eth0: Don't Match (but seems to be UP) DEBUG: if eth1: Don't Match (but seems to be UP) DEBUG: if eth2: OK using eth2, addr: 172.16.6.60, MTU: 1500 It supposedly binds to eth2. But tcpdump tells another story. Packets get sent out via the default route (eth1) with the IP from eth2 set as the source address. The same happens with tcptraceroute (tcptraceroute-1.5-0.beta7.el5.rf.i386.rpm). I have tried various routing policies, but I have yet to find a solution that works. I have used iptables to log the packets in the OUTPUT chain, but they arrive there with the interface already set to eth1. Can anyone help ? Regards, Mitja Mihelic ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
