Re: nscd and DNS cache
On 16 May 2012 07:41, JD wrote: > I have nscd running. > /etc/resolv.conf starts out with > nameserver 127.0.0.1 > nameserver 192.168.1.254 > > > The 192.168.1.254 is the router, which has been a fast and reliable > resolver. > > So, to test nscd caching behavior, > I browse (using FF) over to any website. > After some time, the address is resolved and the page comes up. > I kill the tab of the page, and open a new tab and aim the browser > at same url. Browser again says: looking up whatevercom and takes > several seconds to resolve it. > > I thought that nscd is supposed to cache the translation from the > first lookup. > > Am I to believe that the browser is NOT using /etc/resolv.conf? > If not, what is it using? > Or could it be that nscd is useless in this respect? nscd should cache host lookups if it is configured correctly. Run nscd -g to see caching statistics and see if they tally with your usage. If all of them are misses then you need to run nscd in debug mode with 'nscd -d' to see why the caching is not working. Make sure you increase the value of debug-level to get verbose messages. An easy test is to use 'getent hosts ' and 'getent ahosts ' and study the nscd logs to see if you get a cache miss everytime. -- Siddhesh Poyarekar http://siddhesh.in -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Random Frequent Session Crashed
For random crashes, look into things like: A buggy screensaver, particularly if you're set up to randomly swap between different screen savers. The CPU cooling is working properly (fans not spinning, or blocked vents). Likewise for graphics card fans, power supply fans, and other case fans. Check that the PSU isn't dying. Granted that's a bit hard to do if you're not into electronics, or don't have another supply to play swapsies with. But, you can often boot up into the BIOS, and find a screen showing what voltages the power supply is feeding to the motherboard. Small fractional differences aren't too much of a problem, such as a 5 volt supply actually being 4.95 volts. But if you see 4.9, or worse, instead, then that's probably cause to be concerned. Likewise for over-voltage. -- [tim@localhost ~]$ uname -r 2.6.27.25-78.2.56.fc9.i686 Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 02:54 PM, JD wrote: > I understand the libs are what make calls to the resolver. But even > the resolver must look > at /etc/resolv.conf. Well, you did say: "Am I to believe that the browser is NOT using /etc/resolv.conf" which to me reads that you were thinking that somehow the browser itself should be using resolv.conf. I'm sorry if I misread what you wrote. > If it is empty, NOTHING gets resolved. Not "entirely" true. With named not running. [egreshko@f16-1 ~]$ cat /etc/resolv.conf # Generated by NetworkManager #search greshko.com #nameserver 192.168.0.55 [egreshko@f16-1 ~]$ ping misty PING misty (192.168.0.55) 56(84) bytes of data. 64 bytes from misty (192.168.0.55): icmp_req=1 ttl=64 time=1.99 ms since /etc/nsswitch.conf contains hosts: files dns and /etc/hosts contains 192.168.0.55 misty if you take the "files" out of the hosts linethen NOTHING gets resolved. > I was using nscd thinking it is a lightweight caching resolver. But as > it turns out it is useless. > Time for fedora to bury it :) > Re: My router: it does very little if any caching - and has no > configuration for it at all. > > I will try bind. I've not used itbut have heard good things about dnsmasq which, according to yum info, is A lightweight DHCP/caching DNS server. -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 01:10 AM, Siddhesh Poyarekar wrote: On 16 May 2012 07:41, JD wrote: I have nscd running. /etc/resolv.conf starts out with nameserver 127.0.0.1 nameserver 192.168.1.254 The 192.168.1.254 is the router, which has been a fast and reliable resolver. So, to test nscd caching behavior, I browse (using FF) over to any website. After some time, the address is resolved and the page comes up. I kill the tab of the page, and open a new tab and aim the browser at same url. Browser again says: looking up whatevercom and takes several seconds to resolve it. I thought that nscd is supposed to cache the translation from the first lookup. Am I to believe that the browser is NOT using /etc/resolv.conf? If not, what is it using? Or could it be that nscd is useless in this respect? nscd should cache host lookups if it is configured correctly. Run nscd -g to see caching statistics and see if they tally with your usage. If all of them are misses then you need to run nscd in debug mode with 'nscd -d' to see why the caching is not working. Make sure you increase the value of debug-level to get verbose messages. An easy test is to use 'getent hosts' and 'getent ahosts ' and study the nscd logs to see if you get a cache miss everytime. When I have more time I might debug it. Perhaps you have more time on your hands? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 01:29 AM, Ed Greshko wrote: On 05/16/2012 02:54 PM, JD wrote: I understand the libs are what make calls to the resolver. But even the resolver must look at /etc/resolv.conf. Well, you did say: "Am I to believe that the browser is NOT using /etc/resolv.conf" which to me reads that you were thinking that somehow the browser itself should be using resolv.conf. I'm sorry if I misread what you wrote. If it is empty, NOTHING gets resolved. Not "entirely" true. With named not running. [egreshko@f16-1 ~]$ cat /etc/resolv.conf # Generated by NetworkManager #search greshko.com #nameserver 192.168.0.55 [egreshko@f16-1 ~]$ ping misty PING misty (192.168.0.55) 56(84) bytes of data. 64 bytes from misty (192.168.0.55): icmp_req=1 ttl=64 time=1.99 ms since /etc/nsswitch.conf contains hosts: files dns and /etc/hosts contains 192.168.0.55 misty if you take the "files" out of the hosts linethen NOTHING gets resolved. nsswitch comes out of the box with files listed first for hosts resolution. I do not modify it. I was using nscd thinking it is a lightweight caching resolver. But as it turns out it is useless. Time for fedora to bury it :) Re: My router: it does very little if any caching - and has no configuration for it at all. I will try bind. I've not used itbut have heard good things about dnsmasq which, according to yum info, is A lightweight DHCP/caching DNS server. I have used dnsmasq as well, and communicated with it's author a couple of years ago. But as I recall, it did not seem to help much, as I observed that browsing to a website with just a couple of minutes lapse time, FF showed on the status line it was looking up the domain. Perhaps the cache expiry was set to a very short time? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
... or try dnsmasq suomi On 05/16/2012 08:54 AM, JD wrote: On Tue, May 15, 2012 at 9:20 PM, Ed Greshko wrote: On 05/16/2012 10:11 AM, JD wrote: I have nscd running. /etc/resolv.conf starts out with nameserver 127.0.0.1 nameserver 192.168.1.254 The 192.168.1.254 is the router, which has been a fast and reliable resolver. So, to test nscd caching behavior, I browse (using FF) over to any website. After some time, the address is resolved and the page comes up. I kill the tab of the page, and open a new tab and aim the browser at same url. Browser again says: looking up whatevercom and takes several seconds to resolve it. I thought that nscd is supposed to cache the translation from the first lookup. Am I to believe that the browser is NOT using /etc/resolv.conf? If not, what is it using? Or could it be that nscd is useless in this respect? I've not looked at nscd in a long timebut I never could see the value in it and never could get it to what I thought was a working or useful configuration for my needs. No browser or application uses resolv.conf directly. They make calls to the resolver libraries which in turn use it. IMO, if your router does caching name services there really is no benefit to having systems do their own caching since the overhead of local requests should be small. However, it seems that your router may not be caching since it is taking several seconds. In cases where the router isn't doing caching, or is doing it poorly, I prefer to simply run bind on a single server and point all the systems to it for resolution. With the current Fedora systems this is easy. All one need to do is install bind and bind-chroot and enable/start the service. On the "bind" host all you need is 127.0.0.1 defined as a nameserver. Then, if you use a tool such as "wireshark" you will see that requests will only go out if the answer is not in the cache or the TTL has expired. I understand the libs are what make calls to the resolver. But even the resolver must look at /etc/resolv.conf. If it is empty, NOTHING gets resolved. I was using nscd thinking it is a lightweight caching resolver. But as it turns out it is useless. Time for fedora to bury it :) Re: My router: it does very little if any caching - and has no configuration for it at all. I will try bind. Thanx Ed. JD -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
fedora skrev 16.05.12 10:33: > ... or try dnsmasq > > suomi > > On 05/16/2012 08:54 AM, JD wrote: >> On Tue, May 15, 2012 at 9:20 PM, Ed Greshko >> wrote: >>> On 05/16/2012 10:11 AM, JD wrote: I have nscd running. /etc/resolv.conf starts out with nameserver 127.0.0.1 nameserver 192.168.1.254 The 192.168.1.254 is the router, which has been a fast and reliable resolver. So, to test nscd caching behavior, I browse (using FF) over to any website. After some time, the address is resolved and the page comes up. I kill the tab of the page, and open a new tab and aim the browser at same url. Browser again says: looking up whatevercom and takes several seconds to resolve it. I thought that nscd is supposed to cache the translation from the first lookup. Am I to believe that the browser is NOT using /etc/resolv.conf? If not, what is it using? Or could it be that nscd is useless in this respect? >>> >>> I've not looked at nscd in a long timebut I never could see the >>> value in it and >>> never could get it to what I thought was a working or useful >>> configuration for my needs. >>> >>> No browser or application uses resolv.conf directly. They make >>> calls to the resolver >>> libraries which in turn use it. >>> >>> IMO, if your router does caching name services there really is no >>> benefit to having >>> systems do their own caching since the overhead of local requests >>> should be small. >>> However, it seems that your router may not be caching since it is >>> taking several seconds. >>> >>> In cases where the router isn't doing caching, or is doing it >>> poorly, I prefer to >>> simply run bind on a single server and point all the systems to it >>> for resolution. >>> >>> With the current Fedora systems this is easy. All one need to do is >>> install bind and >>> bind-chroot and enable/start the service. On the "bind" host all >>> you need is >>> 127.0.0.1 defined as a nameserver. Then, if you use a tool such as >>> "wireshark" you >>> will see that requests will only go out if the answer is not in the >>> cache or the TTL >>> has expired. >>> >> I understand the libs are what make calls to the resolver. But even >> the resolver must look >> at /etc/resolv.conf. If it is empty, NOTHING gets resolved. >> I was using nscd thinking it is a lightweight caching resolver. But as >> it turns out it is useless. >> Time for fedora to bury it :) >> Re: My router: it does very little if any caching - and has no >> configuration for it at all. >> >> I will try bind. >> >> Thanx Ed. >> >> JD HI Why do you have 127.0.0.1 in /etc/resolv.conf? Could it be that your computer ask himself to resolv this ip and as he can't do that then he get to your router and ask? Do you have the same behaviour when only your router's ip adress is in /etc/resolv.conf? kind regards Daniel -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 01:29 AM, Ed Greshko wrote: On 05/16/2012 02:54 PM, JD wrote: I understand the libs are what make calls to the resolver. But even the resolver must look at /etc/resolv.conf. Well, you did say: "Am I to believe that the browser is NOT using /etc/resolv.conf" which to me reads that you were thinking that somehow the browser itself should be using resolv.conf. I'm sorry if I misread what you wrote. If it is empty, NOTHING gets resolved. Not "entirely" true. With named not running. [egreshko@f16-1 ~]$ cat /etc/resolv.conf # Generated by NetworkManager #search greshko.com #nameserver 192.168.0.55 [egreshko@f16-1 ~]$ ping misty PING misty (192.168.0.55) 56(84) bytes of data. 64 bytes from misty (192.168.0.55): icmp_req=1 ttl=64 time=1.99 ms since /etc/nsswitch.conf contains hosts: files dns and /etc/hosts contains 192.168.0.55 misty if you take the "files" out of the hosts linethen NOTHING gets resolved. I was using nscd thinking it is a lightweight caching resolver. But as it turns out it is useless. Time for fedora to bury it :) Re: My router: it does very little if any caching - and has no configuration for it at all. I will try bind. I've not used itbut have heard good things about dnsmasq which, according to yum info, is A lightweight DHCP/caching DNS server. ps -ef | grep dnsmasq nobody2344 1 0 May14 ?00:00:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override where is dnsmask starter script? I looked in /lib/systemd/system and do not find these arguments there nor in the env file listed in the start systemd start script. Also checked /etc/systemd/system Nothing there that betrays these args, Seems that it is started by some other service?? Like vboxnet? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 03:18 AM, Daniel Bossert wrote: fedora skrev 16.05.12 10:33: ... or try dnsmasq suomi On 05/16/2012 08:54 AM, JD wrote: On Tue, May 15, 2012 at 9:20 PM, Ed Greshko wrote: On 05/16/2012 10:11 AM, JD wrote: I have nscd running. /etc/resolv.conf starts out with nameserver 127.0.0.1 nameserver 192.168.1.254 The 192.168.1.254 is the router, which has been a fast and reliable resolver. So, to test nscd caching behavior, I browse (using FF) over to any website. After some time, the address is resolved and the page comes up. I kill the tab of the page, and open a new tab and aim the browser at same url. Browser again says: looking up whatevercom and takes several seconds to resolve it. I thought that nscd is supposed to cache the translation from the first lookup. Am I to believe that the browser is NOT using /etc/resolv.conf? If not, what is it using? Or could it be that nscd is useless in this respect? I've not looked at nscd in a long timebut I never could see the value in it and never could get it to what I thought was a working or useful configuration for my needs. No browser or application uses resolv.conf directly. They make calls to the resolver libraries which in turn use it. IMO, if your router does caching name services there really is no benefit to having systems do their own caching since the overhead of local requests should be small. However, it seems that your router may not be caching since it is taking several seconds. In cases where the router isn't doing caching, or is doing it poorly, I prefer to simply run bind on a single server and point all the systems to it for resolution. With the current Fedora systems this is easy. All one need to do is install bind and bind-chroot and enable/start the service. On the "bind" host all you need is 127.0.0.1 defined as a nameserver. Then, if you use a tool such as "wireshark" you will see that requests will only go out if the answer is not in the cache or the TTL has expired. I understand the libs are what make calls to the resolver. But even the resolver must look at /etc/resolv.conf. If it is empty, NOTHING gets resolved. I was using nscd thinking it is a lightweight caching resolver. But as it turns out it is useless. Time for fedora to bury it :) Re: My router: it does very little if any caching - and has no configuration for it at all. I will try bind. Thanx Ed. JD HI Why do you have 127.0.0.1 in /etc/resolv.conf? Could it be that your computer ask himself to resolv this ip and as he can't do that then he get to your router and ask? Do you have the same behaviour when only your router's ip adress is in /etc/resolv.conf? kind regards Daniel Well, if I recall correctly, using a caching dns daemon requires that the first entry in /etc/resolv.conf be 127.0.0.1 followed by external nameservers' ip addresses. And yes, re: same behavior when only router's ip address is in resolv.conf. As I indicated, the router does not seem to be caching anything, and I believe for good reason: reduce production cost - saving a few pennies per unit can amount to millions of dollars. I have worked at industries that did similar cost saving (or profit creating) design decisions. Just my $.02's worth. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On Tue, 15 May 2012 23:54:03 -0700 JD wrote: > I was using nscd thinking it is a lightweight caching resolver. But as > it turns out it is useless. > Time for fedora to bury it :) It isn't useless for me at work: It is the only thing that makes NIS lookups reliable. At some point in time, glibc apparently changed the timeout for NIS to something like 3 nanoseconds :-). -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 04:27 PM, JD wrote: > I have used dnsmasq as well, and communicated with it's author > a couple of years ago. > But as I recall, it did not seem to help much, as I observed that > browsing to a website with just a couple of minutes lapse time, > FF showed on the status line it was looking up the domain. > Perhaps the cache expiry was set to a very short time? > > 2 things may be coming into play. 1st it "could" be that there is a cache time setting in dnsmasq. 2nd the owners of a domain, and by definition, who control the settings of the master DNS server for their domains set up a TTL for their records. If they set this to a low value you may see this problem. As a mater of fact, I've seen cases where the TTL has been set to as low as 300 seconds. -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Restarting services
F16
After a recent yum update, "needs-restarting" says that colord should be
restarted. OK, let's see:
1) pstree says that colord's parent is systemd
2) "systemctl list-units" doesn't mention colord
3) There is no man page for colord
4) The colord docs ("rpm -qd colord") don't say anything about using
signals to restart, or indeed anything about restarting.
5) There is no mention of colord in any file under /etc
Obviously I could log out and in again, but I'm interested in exploring
just how one is supposed to find this kind of information in the general
case -- not just for colord --other than asking the list or reading the
source code.
Thoughts?
poc
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: Restarting services
Am 16.05.2012 14:18, schrieb Patrick O'Callaghan: > F16 > > After a recent yum update, "needs-restarting" says that colord should be > restarted. OK, let's see: > > 1) pstree says that colord's parent is systemd > 2) "systemctl list-units" doesn't mention colord it does and "systemctl restart colord.service" works like for any other service [root@rh:~]$ /bin/systemctl --no-pager --full list-units | grep colord colord-sane.service loaded active running Daemon for monitoring attached scanners and registering them with colord colord.service loaded active running Daemon for managing, installing and generating color profiles _ [root@rh:~]$ systemctl status colord.service colord.service - Daemon for managing, installing and generating color profiles Loaded: loaded (/lib/systemd/system/colord.service; disabled) Active: active (running) since Wed, 16 May 2012 14:25:34 +0200; 15s ago Main PID: 12862 (colord) CGroup: name=systemd:/system/colord.service └ 12862 /usr/libexec/colord [root@rh:~]$ systemctl restart colord.service [root@rh:~]$ systemctl status colord.service colord.service - Daemon for managing, installing and generating color profiles Loaded: loaded (/lib/systemd/system/colord.service; disabled) Active: active (running) since Wed, 16 May 2012 14:25:57 +0200; 1s ago Main PID: 12884 (colord) CGroup: name=systemd:/system/colord.service └ 12884 /usr/libexec/colord signature.asc Description: OpenPGP digital signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Connecting to a Zeroconfig/Avahi printer
On Tue, May 15, 2012 at 05:25:39PM -0400, Bill Davidsen wrote: > Reindl Harald wrote: > > > > > >Am 15.05.2012 16:24, schrieb Steven Stern: > >>On 05/15/2012 08:57 AM, Paul W. Frields wrote: > >>>On Mon, May 14, 2012 at 11:25:47PM +0200, Reindl Harald wrote: > > > Am 14.05.2012 23:22, schrieb Steven Stern: > >I have a really nice HP printer that's currently connected via USB cable > >to this system. I need to move it out of cable range. My OS/X and iOS > >devices are able to find it and print to it using the magic of Bonjour. > > Is there a way for Fedora to use it via Avahi, rather than ipp and > >giving the printer a fixed IP address? > > > http://localhost:631/ > > CUPS does find network-printers via avahi > >>> > >>>Ensure that your Fedora client system's firewall has port 5353/udp > >>>(mDNS) and 631/udp (IPP client) open, and things should generally Just > >>>Work(tm). > >>> > >> > >>It seems to be more than 5353 and 631. With the iptables service > >>running, I don't see the printer in CUPS. If I stop the iptables > >>service, I do. What's missing here? > >> > > > >it is only 5353 used BUT UDP, 100% sure and no there is no need > >to open jetdirect INCOMING or other voodo > > > >avahi works on UDP and your UDP rule looks strange > >what is the "224.0.0.251" for? > > > Isn't that multicast? Can't conveniently look it up at the moment, > but that rings a bell. Correct, it's a multicast address. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 03:33 AM, Tom Horsley wrote: On Tue, 15 May 2012 23:54:03 -0700 JD wrote: I was using nscd thinking it is a lightweight caching resolver. But as it turns out it is useless. Time for fedora to bury it :) It isn't useless for me at work: It is the only thing that makes NIS lookups reliable. At some point in time, glibc apparently changed the timeout for NIS to something like 3 nanoseconds :-). 3 ns?? So, what did you do to make it work? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Restarting services
On Wed, May 16, 2012 at 7:58 AM, Reindl Harald wrote: > > 2) "systemctl list-units" doesn't mention colord > > it does and "systemctl restart colord.service" works > like for any other service > > [root@rh:~]$ /bin/systemctl --no-pager --full list-units | grep colord > colord-sane.service > loaded active running Daemon for monitoring attached scanners and > registering them with colord > colord.service > loaded active running Daemon for managing, installing and generating > color profiles > This is what I get: [poc@bree:~] /bin/systemctl --no-pager --full list-units | grep colord [poc@bree:~] However the process exists: [poc@bree:~] pgrep -fl colord 2214 /usr/libexec/colord Although it appears to be dead: [poc@bree:~] systemctl status colord.service colord.service - Daemon for managing, installing and generating color profiles Loaded: loaded (/lib/systemd/system/colord.service; disabled) Active: inactive (dead) CGroup: name=systemd:/system/colord.service Note that this after logging out and in again. So now the questions now are: 1) How do I find out about a service managed by systemd independantly of whether it is currently running or not? 2) Why does systemd say the service is inactive if the process is running? (note that I was able to restart it using systemctl and now it does appear as active). poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 03:33 AM, Ed Greshko wrote: On 05/16/2012 04:27 PM, JD wrote: I have used dnsmasq as well, and communicated with it's author a couple of years ago. But as I recall, it did not seem to help much, as I observed that browsing to a website with just a couple of minutes lapse time, FF showed on the status line it was looking up the domain. Perhaps the cache expiry was set to a very short time? 2 things may be coming into play. 1st it "could" be that there is a cache time setting in dnsmasq. 2nd the owners of a domain, and by definition, who control the settings of the master DNS server for their domains set up a TTL for their records. If they set this to a low value you may see this problem. As a mater of fact, I've seen cases where the TTL has been set to as low as 300 seconds. Interesting point. Hard to believe that most domain controllers would that. Must be a small percentage? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
problem with subversion python bindings
Just updated a Fedora 15 box and this updated subversion-libs-1.6.18-1.fc15.x86_64 mod_dav_svn-1.6.18-1.fc15.x86_64 subversion-1.6.18-1.fc15.x86_64 Now my post-commit hook to send mail doesn't work because it can't import svn.fs. Any simple python code like... #!/usr/bin/env python import svn.fs Can't find the subversion python bindings... $ ./Junk.py Traceback (most recent call last): File "./Junk.py", line 3, in import svn.fs ImportError: No module named svn.fs What can I do to fix this? Pete -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 03:33 AM, Ed Greshko wrote: On 05/16/2012 04:27 PM, JD wrote: I have used dnsmasq as well, and communicated with it's author a couple of years ago. But as I recall, it did not seem to help much, as I observed that browsing to a website with just a couple of minutes lapse time, FF showed on the status line it was looking up the domain. Perhaps the cache expiry was set to a very short time? 2 things may be coming into play. 1st it "could" be that there is a cache time setting in dnsmasq. 2nd the owners of a domain, and by definition, who control the settings of the master DNS server for their domains set up a TTL for their records. If they set this to a low value you may see this problem. As a mater of fact, I've seen cases where the TTL has been set to as low as 300 seconds. Interesting point. Hard to believe that most domain controllers would that. Must be a small percentage? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
[SOLVED] Re: problem with subversion python bindings
On 5/16/2012 8:49 AM, Pete Stieber wrote: Just updated a Fedora 15 box and this updated subversion-libs-1.6.18-1.fc15.x86_64 mod_dav_svn-1.6.18-1.fc15.x86_64 subversion-1.6.18-1.fc15.x86_64 Now my post-commit hook to send mail doesn't work because it can't import svn.fs. Any simple python code like... #!/usr/bin/env python import svn.fs Can't find the subversion python bindings... $ ./Junk.py Traceback (most recent call last): File "./Junk.py", line 3, in import svn.fs ImportError: No module named svn.fs What can I do to fix this? Just upgraded from 14 to 15 yesterday and the python bindings are now in a separate rpm. Needed to use: yum install subversion-python Pete -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 11:47 PM, JD wrote: > Interesting point. Hard to believe that most domain controllers would that. > Must be a small percentage? I have no idea what percentage it may be. But 300 seems a bit low I'd have to do some research but it very well may be that sites set their TTL's low in an attempt to balance DNS server load with load balancing (round robin) of their web sites. It seems that the TTL for www.cnn.com is set to 150 seconds. I'd have to check But when you do a look up on www.cnn.com it will return 4 IP addresses. Now, since bind would have that in its cache it wouldn't have to send out a query. What I don't know is if an application would make a request would the list be returned in the same order every time to the requesting application? In other words, if the TTL is not set low, would that defeat the round robin technique. Interesting things to investigate.if I really had the time. -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Execution of /etc/rc.d/rc.local
On Tue, 15 May 2012 16:52:08 -0700 Geoffrey Leach wrote: > root@puget[10]->cat /etc/rc.d/rc.local > #! /bin/sh ^ you have a " " here that shouldn't be there. Should be simply: "#!/bin/sh" kevin signature.asc Description: PGP signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Execution of /etc/rc.d/rc.local
On 05/17/2012 12:14 AM, Kevin Fenzi wrote: > On Tue, 15 May 2012 16:52:08 -0700 > Geoffrey Leach wrote: > >> root@puget[10]->cat /etc/rc.d/rc.local >> #! /bin/sh > ^ you have a " " here that shouldn't be there. > > Should be simply: "#!/bin/sh" > > That was my theory too But I like to test my theories So I created an rc.local file with the following contents... #! /bin/sh -e #exit 0 touch /tmp/ and it worked just fine -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On Wed, 2012-05-16 at 09:47 -0600, JD wrote: > On 05/16/2012 03:33 AM, Ed Greshko wrote: > I've seen cases where the > TTL has been set to as low as 300 seconds. > Interesting point. Hard to believe that most domain controllers would that. > Must be a small percentage? As a DNS administrator, I can say that there are a lot of things that go into determining a good setting for the TTL. There is a default TTL for the entire zone, and you can also set the TTL on individual records. As we all presumably know, the DNS is a caching system. This was originally done to lower the amount of DNS traffic on the net. But the drawback to having your data cached all over the net is that it is hard to change it. And sometimes DNS data does need to change, so it is fairly common practice to lower the TTL to values like 300 seconds (5 minutes) when you know that a given record is going to be changed, and you need the change to propagate quickly (e.g. the IP address of your web site, which is a real-life example from my workplace recently). There are also domains that set a very low TTL for their entire zone. Sometimes this is justified; consider something like dyndns.org, which exists specifically to resolve addresses that can change unexpectedly (e.g. gregandeva.dyndns.org points to my home firewall/router, and it can change whenever the Comcast DHCP server feels like changing it, and does change pretty much every time the router is rebooted, which also happens every time I change certain settings; it would be a royal pain if my IP address could not always be accurately resolved). dyndns.org sets the TTL so low that caching is effectively disabled for any records in their domain, but customers subscribe to their service because this is exactly what they want. Sometimes also domain administrators who don't really understand the purpose of caching or how it works will lower the TTL for their entire domain just so that the occasional change they need to make will always propagate quickly. I don't recommend that because it more-or-less defeats the purpose of having caching in DNS servers in the first place. It is no substitute for a little advance planning (as I have told sysadmins at work who fail to think about this ahead of time and are now upset because a change they need to make is not going to propagate for a day or two). As a (possibly) interesting aside: in the early days of NSFnet, which is when the IP net as it existed expanded from government and defense contractors only (the old ARPAnet) to include universities and research institutions (but before the Internet became what it is now where nearly everybody in the world is on it), there was a traffic study done, and it showed that 60% of the packets on the net were DNS queries or responses. This was before DNS servers would cache non-authoritative data. That's probably what we would have now were it not for DNS caching. --Greg -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: [SOLVED] Re: problem with subversion python bindings
On 5/16/2012 12:04 PM, Pete Stieber wrote: > On 5/16/2012 8:49 AM, Pete Stieber wrote: >> Just updated a Fedora 15 box and this updated >> >> subversion-libs-1.6.18-1.fc15.x86_64 >> mod_dav_svn-1.6.18-1.fc15.x86_64 >> subversion-1.6.18-1.fc15.x86_64 >> >> Now my post-commit hook to send mail doesn't work because it can't >> import svn.fs. Any simple python code like... >> >> #!/usr/bin/env python >> >> import svn.fs >> >> Can't find the subversion python bindings... >> >> $ ./Junk.py >> Traceback (most recent call last): >> File "./Junk.py", line 3, in >> import svn.fs >> ImportError: No module named svn.fs >> >> What can I do to fix this? > > Just upgraded from 14 to 15 yesterday and the python bindings are now in > a separate rpm. Needed to use: > > yum install subversion-python Why would you update an EOL Fedora release to a Fedora release that will be EOL in about a month from now? -- David -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On Thu, 2012-05-17 at 00:13 +0800, Ed Greshko wrote: > when you do a look up on www.cnn.com it will return 4 IP > addresses. Now, since bind would have that in its cache it wouldn't have to > send out > a query. What I don't know is if an application would make a request would > the list > be returned in the same order every time to the requesting application? In > other > words, if the TTL is not set low, would that defeat the round robin technique. Unfortunately, there is no guarantee that a client resolver will actually use the IP addresses in the order they are presented by the DNS server. Nothing in the DNS spec requires them to do so. > > Interesting things to investigate.if I really had the time. My experience says that DNS round robining is actually a poor method of load balancing. I'm surprised to see a large site like CNN resorting to this (if that's really what they are doing this for). Perhaps in combination with a low TTL and a modified DNS server, they can send out a completely different set of IPs every few minutes, and achieve a sort of crude load balancing that way, but I think load balancing works better if you just send out a single IP and use a load balancer that you can control, such as LVS (Linux Virtual Server) that can farm out incoming connections to a single virtual address out to multiple real addresses. --Greg -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/17/2012 12:28 AM, Greg Woods wrote: > On Thu, 2012-05-17 at 00:13 +0800, Ed Greshko wrote: >> when you do a look up on www.cnn.com it will return 4 IP >> addresses. Now, since bind would have that in its cache it wouldn't have to >> send out >> a query. What I don't know is if an application would make a request would >> the list >> be returned in the same order every time to the requesting application? In >> other >> words, if the TTL is not set low, would that defeat the round robin >> technique. > Unfortunately, there is no guarantee that a client resolver will > actually use the IP addresses in the order they are presented by the DNS > server. Nothing in the DNS spec requires them to do so. Yeah I know there is no spec... I'm just expecting the clients to be "dumb" and take the first one in the stack. :-) :-) > >> Interesting things to investigate.if I really had the time. > My experience says that DNS round robining is actually a poor method of > load balancing. I'm surprised to see a large site like CNN resorting to > this (if that's really what they are doing this for). Perhaps in > combination with a low TTL and a modified DNS server, they can send out > a completely different set of IPs every few minutes, and achieve a sort > of crude load balancing that way, but I think load balancing works > better if you just send out a single IP and use a load balancer that you > can control, such as LVS (Linux Virtual Server) that can farm out > incoming connections to a single virtual address out to multiple real > addresses. Yes... I suppose one also has to ask if the load balancing is meant to be server or network balancing. -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Execution of /etc/rc.d/rc.local
On 05/16/2012 09:14:11 AM, Kevin Fenzi wrote: > On Tue, 15 May 2012 16:52:08 -0700 > Geoffrey Leach wrote: > > > root@puget[10]->cat /etc/rc.d/rc.local > > #! /bin/sh > > ^ you have a " " here that shouldn't be there. > > Should be simply: "#!/bin/sh" Blush! The # is where it should be. Just a copy error. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On Wed, May 16, 2012 at 9:13 AM, Ed Greshko wrote: > On 05/16/2012 11:47 PM, JD wrote: >> Interesting point. Hard to believe that most domain controllers would that. >> Must be a small percentage? > > I have no idea what percentage it may be. But 300 seems a bit low > > I'd have to do some research but it very well may be that sites set their > TTL's low > in an attempt to balance DNS server load with load balancing (round robin) of > their > web sites. > > It seems that the TTL for www.cnn.com is set to 150 seconds. > > I'd have to check But when you do a look up on www.cnn.com it will > return 4 IP > addresses. Now, since bind would have that in its cache it wouldn't have to > send out > a query. What I don't know is if an application would make a request would > the list > be returned in the same order every time to the requesting application? In > other > words, if the TTL is not set low, would that defeat the round robin technique. > > Interesting things to investigate.if I really had the time. > > -- > Never be afraid to laugh at yourself, after all, you could be missing out on > the joke > of the century. -- Dame Edna Everage > -- > users mailing list > users@lists.fedoraproject.org > To unsubscribe or change subscription options: > https://admin.fedoraproject.org/mailman/listinfo/users > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines > Have a question? Ask away: http://ask.fedoraproject.org Try it with the google domain addresses. I believe they use short ttl times. I know that by testing one of their addresses and nailing it in my hosts file. After a short time, maybe 5 minutes, connecting to google.come would take forever or even not connect at all. But even this experience does not necessarily say where the problem really is. Sometimes our router really starts incurring very long delay times for connection on one of our machines, while others seem to breeze by. Biggest problems we have seen in the house is with wireless connections. In spite of each machine showing 100% signal strength, connection times are considerably longer than the hard wired machine. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On Wed, 16 May 2012 09:42:20 -0600 JD wrote: > > It isn't useless for me at work: It is the only thing that makes > > NIS lookups reliable. At some point in time, glibc apparently > > changed the timeout for NIS to something like 3 nanoseconds :-). > 3 ns?? So, what did you do to make it work? The smiley was for the 3 ns value. I have no idea what it actually is, but NIS only functions error free if I am running nscd on my local system. The slightest amount of network traffic that slows down the local network always results in NIS errors unless I'm running nscd. This happened somewhere around fedora 12 or 13 I seem to recall. Never ran nscd before that, and never had a problem, and none of the local network infrastructure changed, so I figured it must be something in libc that was more sensitive to slight delays in responses. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Samsung Print driver Info
Fedora 16,17 Samsung Printer drivers. If you go onto Samsung driver download site and download a Drivers for a CLX3175FN printer for Fedora 16,17 the driver they have won't work . They only work on Fedora 15 and previous. The updated drivers for Fedora 16, the CLX3175FN are in the CLX3185 drivers download. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 12:41 PM, Tom Horsley wrote: On Wed, 16 May 2012 09:42:20 -0600 JD wrote: It isn't useless for me at work: It is the only thing that makes NIS lookups reliable. At some point in time, glibc apparently changed the timeout for NIS to something like 3 nanoseconds :-). 3 ns?? So, what did you do to make it work? The smiley was for the 3 ns value. I have no idea what it actually is, but NIS only functions error free if I am running nscd on my local system. The slightest amount of network traffic that slows down the local network always results in NIS errors unless I'm running nscd. This happened somewhere around fedora 12 or 13 I seem to recall. Never ran nscd before that, and never had a problem, and none of the local network infrastructure changed, so I figured it must be something in libc that was more sensitive to slight delays in responses. I see. Well, I must not have configured nscd properly then. Currently enabled and running dnsmasq with the following config options in /etc/dnsmasq.conf: interface=em1 interface=lo except-interface=virbr0 listen-address=10.0.0.1 cache-size=2000 no-negcache conf-dir=/etc/dnsmasq.d Per documentation, the interfaces are what it listens to for resolution requests. I assume the resolver library (/lib/libnss_mdns4_minimal.so.2) configured in /etc/nsswitch.conf: hosts: files mdns4_minimal dns [NOTFOUND=return] myhostname looks in /etc/resolv.conf to see that the first line is 127.0.0.1. If there is a dnsmasq config option to force a longer ttl (i.e. to delay invalidation of a translated domain), I do not know it. Also, is the line listen-address=10.0.0.1 redundant? since it is the address of interface em1, which is already stated? If you have any improvements I can make to the config options, please share them. Thanx, JD -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Execution of /etc/rc.d/rc.local
On 16.05.2012, Kevin Fenzi wrote: > ^ you have a " " here that shouldn't be there. > Should be simply: "#!/bin/sh" This is not true, you can hav as many blanks as you like. Try it. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: [389-users] Strange Disk IO issue
On 05/16/2012 11:19 AM, Brad Schuetz wrote: On 05/16/2012 06:16 AM, Paul Robert Marino wrote: The exact timing of the issue is to strange is there a backup job running at midnight. Or some other timed job that could be eating the ram or disk IO. Possibly one that is reliant on ldap queries that would otherwise be inocuious. It doesn't happen at midnight, it's 24 hours from when the process was started, so I can restart dirsrv at 3:17pm on Wednesday and at right around 3:17pm on Thursday that server will go to 100% disk IO usage. The default tombstone purge interval is 1 day, which seems to fit what you are seeing. The tombstone reap thread will start every 24 hours to find tombstone entries that can be deleted. The default retention period for tombstones is 1 week. It is possible that you have a large number of tombstone entries that need to be deleted. This will occur independently on all of your server instances. This is controlled by the "nsDS5ReplicaTombstonePurgeInterval" and "nsDS5ReplicaPurgeDelay" attributes in your "cn=replica,cn=,cn=mapping tree,cn=config" entry. You can search for "(objectclass=nstombstone)" as Directory Manager to see how many tombstone entries you have. I've restarted the servers at totally random times to reproduce this issue, and currently restart, via cron, all my ldap servers twice per day at randomly selected times of the day to make sure that both they are restarted before the 24 hours hits, and so that no more than 1 dirsrv process is being restarted at the same time. Keep in mind, the ldap queries load has not changed from the setup I was running prior to this which was running (much) older versions of the 389 server software. In fact, as part of this system upgrade, additional servers were added to reduce the individual load on each server. -- Brad -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: Execution of /etc/rc.d/rc.local
On Wed, 16 May 2012 21:23:39 +0200 Heinz Diehl wrote: > This is not true, you can hav as many blanks as you like. > Try it. Not as many as you like - I think the exec() service looks only at about the first 32 characters or something like that. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 10:39 AM, Ed Greshko wrote: On 05/17/2012 12:28 AM, Greg Woods wrote: On Thu, 2012-05-17 at 00:13 +0800, Ed Greshko wrote: when you do a look up on www.cnn.com it will return 4 IP addresses. Now, since bind would have that in its cache it wouldn't have to send out a query. What I don't know is if an application would make a request would the list be returned in the same order every time to the requesting application? In other words, if the TTL is not set low, would that defeat the round robin technique. Unfortunately, there is no guarantee that a client resolver will actually use the IP addresses in the order they are presented by the DNS server. Nothing in the DNS spec requires them to do so. Yeah I know there is no spec... I'm just expecting the clients to be "dumb" and take the first one in the stack. :-) :-) Interesting things to investigate.if I really had the time. My experience says that DNS round robining is actually a poor method of load balancing. I'm surprised to see a large site like CNN resorting to this (if that's really what they are doing this for). Perhaps in combination with a low TTL and a modified DNS server, they can send out a completely different set of IPs every few minutes, and achieve a sort of crude load balancing that way, but I think load balancing works better if you just send out a single IP and use a load balancer that you can control, such as LVS (Linux Virtual Server) that can farm out incoming connections to a single virtual address out to multiple real addresses. Yes... I suppose one also has to ask if the load balancing is meant to be server or network balancing. Well, after running dnsmasq with the configuration I just emailed, I see the following behavior of firefox vs. running nslookup on command line. FF, even after resolving google.com only a minute ago, is still spinning saying: lookup up www.google.com whereas , on the command line, I run nslookup www.google.com and almost instantly, I get Server:127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: Name:google.com Address: 74.125.239.1 Name:google.com Address: 74.125.239.2 Name:google.com Address: 74.125.239.3 Name:google.com Address: 74.125.239.4 Name:google.com Address: 74.125.239.5 Name:google.com Address: 74.125.239.6 Name:google.com Address: 74.125.239.7 Name:google.com Address: 74.125.239.8 Name:google.com Address: 74.125.239.9 Name:google.com Address: 74.125.239.14 Name:google.com Address: 74.125.239.0 and FF is still spinning waiting for the resolution. Does anyone see this discrepancy? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Execution of /etc/rc.d/rc.local
On Wed, 16 May 2012 15:50:14 -0400 Tom Horsley wrote: > On Wed, 16 May 2012 21:23:39 +0200 > Heinz Diehl wrote: > > > This is not true, you can hav as many blanks as you like. > > Try it. > > Not as many as you like - I think the exec() service looks > only at about the first 32 characters or something like that. I stand corrected. ;) So, why are you restarting nfs services there? The synclient won't work as rc.local has no connection to your DISPLAY to make changes. How else are you seeing that commands there aren't running? kevin signature.asc Description: PGP signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Execution of /etc/rc.d/rc.local
On 05/16/2012 03:15:24 PM, Kevin Fenzi wrote: > On Wed, 16 May 2012 15:50:14 -0400 > Tom Horsley wrote: > > > On Wed, 16 May 2012 21:23:39 +0200 > > Heinz Diehl wrote: > > > > > This is not true, you can hav as many blanks as you like. > > > Try it. > > > > Not as many as you like - I think the exec() service looks > > only at about the first 32 characters or something like that. > > I stand corrected. ;) > > So, why are you restarting nfs services there? > > The synclient won't work as rc.local has no connection to your > DISPLAY > to make changes. > > How else are you seeing that commands there aren't running? > Thanks for the tip on synclient Restarting nfs services is being done because that was necessary in order to get a connection from the client. Admittedly that was several kernels ago :-) -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/17/2012 03:52 AM, JD wrote: > Well, after running dnsmasq with the configuration I just emailed, > I see the following behavior of firefox vs. running nslookup on command line. > > FF, even after resolving google.com only a minute ago, is still spinning > saying: > lookup up www.google.com > whereas , on the command line, I run nslookup www.google.com > and almost instantly, I get > Server:127.0.0.1 > Address:127.0.0.1#53 > > Non-authoritative answer: > Name:google.com > Address: 74.125.239.1 > Name:google.com > Address: 74.125.239.2 > Name:google.com > Address: 74.125.239.3 > Name:google.com > Address: 74.125.239.4 > Name:google.com > Address: 74.125.239.5 > Name:google.com > Address: 74.125.239.6 > Name:google.com > Address: 74.125.239.7 > Name:google.com > Address: 74.125.239.8 > Name:google.com > Address: 74.125.239.9 > Name:google.com > Address: 74.125.239.14 > Name:google.com > Address: 74.125.239.0 > > and FF is still spinning waiting for the resolution. > > Does anyone see this discrepancy? No Have you tried a different browser? Chrome, or konqueror for example? One SWAG would be to set network.dns.disableIPv6 to true in about:config. -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/16/2012 06:21 PM, Ed Greshko wrote: On 05/17/2012 03:52 AM, JD wrote: Well, after running dnsmasq with the configuration I just emailed, I see the following behavior of firefox vs. running nslookup on command line. FF, even after resolving google.com only a minute ago, is still spinning saying: lookup up www.google.com whereas , on the command line, I run nslookup www.google.com and almost instantly, I get Server:127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: Name:google.com Address: 74.125.239.1 Name:google.com Address: 74.125.239.2 Name:google.com Address: 74.125.239.3 Name:google.com Address: 74.125.239.4 Name:google.com Address: 74.125.239.5 Name:google.com Address: 74.125.239.6 Name:google.com Address: 74.125.239.7 Name:google.com Address: 74.125.239.8 Name:google.com Address: 74.125.239.9 Name:google.com Address: 74.125.239.14 Name:google.com Address: 74.125.239.0 and FF is still spinning waiting for the resolution. Does anyone see this discrepancy? No Have you tried a different browser? Chrome, or konqueror for example? One SWAG would be to set network.dns.disableIPv6 to true in about:config. That value is already set to false. Yes I did try Chrome. Chrome resolves domain names as fast as nslookup . After I browsed to a domain using Chrome, and it almost immediately resolved and it brought in the page, I quickly clicked on the FF workspace and browsed to same domain. FF went into the looking up .. spin dance. Could it be that FF is not using same library as nslookup and Chrome? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: nscd and DNS cache
On 05/17/2012 02:06 PM, JD wrote: > That value is already set to false. I'm suggesting you set it to "true" to disable IPv6. > Yes I did try Chrome. > Chrome resolves domain names as fast as nslookup . > After I browsed to a domain using Chrome, and it almost immediately > resolved and it brought in the page, > I quickly clicked on the FF workspace and browsed to same domain. > FF went into the looking up .. spin dance. > Could it be that FF is not using same library as nslookup and Chrome? I'd be surprised if they used anything other than the standard gethostbyname() -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
/etc/sysconfig/iptables was changed (not by me)
If I did not change /etc/sysconfig/iptables and render it totally open to accept all connections, then what would change it? Would yum update do that? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
