Re: Latest systemd news
Pete Travis writes: Whatever the intent, I hope that everyone discovers it from reading actual documentation instead of inflammatory comments on indignant speculation about the intent behind a one sentence feature description like " resolved: add DNS cache ". I'm not necessarily putting you in that box, Sam, but these discussions tend to feed on themselves and it makes productive discourse difficult. I think that the one-line commit message is the least important issue here. pgpCAuSxsbgBg.pgp Description: PGP signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: failed drive?
Hi, what say `dmesg` about /dev/sdg ? -- Pozdrawiam Michał -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Latest systemd news
On 11/15/2014 08:27 AM, Tom Horsley wrote: I've always called systemd the world's fist computer fungus - it wants to grow over everything. Resistance is futile! Your functionality will be assimilated. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Latest systemd news
On Nov 15, 2014 6:54 AM, "Sam Varshavchik" wrote: > > Making the rounds of various technical mailing lists yesterday, with a subject that's typically a variation of "Just for yucks, and giggles" is a link to a commit to systemd's git, adding DNS caching to systemd; in one, huge 857 line glop. Here's its entire commit message: "resolved: add DNS cache". > > And, it's beauty to read. Made me teary-eyed to know that systemd will cache my DNS queries. Not sure why systemd, all of a sudden, needs to make DNS queries. But if it does, it's going to cache them now! Such a sight to behold makes my heart skip a beat: now, not just bind, or pretty much every DNS server that automatically caches DNS for you – but so will systemd! > > But, seriously folks, systemd's DNS caching achieves absolutely 100% nothing. Really. Surprised? Well, you'll be shocked to know that the DNS server that systemd queries for that DNS RR, such as the stock "bind", already automatically caches all recursive DNS replies!! systemd's own caching produces absolutely zero useful results. On the oft chance that it sends a query for a non-cached RR, the local DNS server will cache the response, before returning it to systemd, and then use the cached response for all future queries. That's what DNS servers do: provide caching for local clients. It's inherent in DNS's design: DNS was explicitly designed to use aggressive caching, it's an internet-wide, distributed, locally cached database. > > Isn't modern technology amazing? > > I'm willing to consider the possibility that I missed something obvious, some obvious value-added result from caching DNS RRs directly by systemd, and I'll stick around for someone to enlighten me; or if Occam's razor applies, and the author of that commit had no idea that bind already automatically caches DNS responses, and, more importantly, that its caching algorithms are a result of painful lessons learned from various DNS cache poisoning attacks, that have circulated around the intertubes, for the last couple of years. > > The only possible use case for this kind of caching approach would be if: > > A) You do not have a local DNS server nearby; and you have non-negligible latencies to whatever DNS server you use. > > B) Your queries tend to be for domains that your DNS servers are not authoritative for, so they'll benefit from local caching. > > So, can someone explain to me how likely this is going to be the case in a typical deployment scenario that systemd is targeted for; in an average corporate environment where systemd's alleged benefits will supposedly shine? > > I would guess that a typical systemd deployment, in a corporate/business environment, will certainly have multiple, low-latency DNS servers nearby, won't that be the case? And, if so, then this is just another potentially exploitable security hole in systemd, nothing more. > > P.S. After I wrote the above, poking around, Google dumped this onto my screen: > > http://seclists.org/oss-sec/2014/q4/592 > > Mental note to myself: go back and check the timestamp of the systemd git commit – before, or after, this was disclosed… > > > -- I haven't read into it much yet, but the vast majority of systemd network functionality is intended almost exclusively to support networking in systemd-nspawn containers. The init system's job is to isolate and manage services; container management is a logical add. Whatever the intent, I hope that everyone discovers it from reading actual documentation instead of inflammatory comments on indignant speculation about the intent behind a one sentence feature description like " resolved: add DNS cache ". I'm not necessarily putting you in that box, Sam, but these discussions tend to feed on themselves and it makes productive discourse difficult. --Pete -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Latest systemd news
On Sat, Nov 15, 2014 at 08:53:59AM -0500, Sam Varshavchik wrote: > Making the rounds of various technical mailing lists yesterday, with > a subject that's typically a variation of "Just for yucks, and > giggles" is a link to a commit to systemd's git, adding DNS caching > to systemd; in one, huge 857 line glop. Here's its entire commit > message: "resolved: add DNS cache". This would be funny if it wasn't real. Seriously, if we'd described systemd to ourselves 10 years ago, we'd think it was parody. I never, ever liked watching train wrecks. And never thought it a good idea to let the inmates run the asylum. -- Dave Ihnat dih...@dminet.com -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: NFS mount -
On 11/15/14 11:30, Tom Horsley wrote: If you are running firewalld then you want to stop firewalld, not iptables. Yes, I've learned that, painfully! Now I am beginning to suspect that NFS is only allowing one computer mounted at a time? This F-20 box is connected but I can't mount it from the F-21a box? Nothing is ever easy! For me anyway it seems. -- http://www.qrz.com/db/W2BOD box10 Fedora-20/64bit Linux/XFCE -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: NFS mount -
On Sat, 15 Nov 2014 07:26:36 -0500 Bob Goodwin - Zuni, Virginia, USA wrote: > I had tested with systemctl stop iptables and that did not help. > > This computer does run the firewalld and works fine with the other NFS > server. If you are running firewalld then you want to stop firewalld, not iptables. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Latest systemd news
On Sat, 15 Nov 2014 10:18:11 -0600 Chris Adams wrote: > Yet more unreasonable scope creep for the systemd project, and this time > reinventing the wheel for no good reason. I've always called systemd the world's fist computer fungus - it wants to grow over everything. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Latest systemd news
Once upon a time, Sam Varshavchik said: > Making the rounds of various technical mailing lists yesterday, with > a subject that's typically a variation of "Just for yucks, and > giggles" is a link to a commit to systemd's git, adding DNS caching > to systemd; in one, huge 857 line glop. Here's its entire commit > message: "resolved: add DNS cache". Yet more unreasonable scope creep for the systemd project, and this time reinventing the wheel for no good reason. There are already perfectly good resolver libraries, caches, etc.; there is no good reason for systemd to grow its own. -- Chris Adams -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: KDE KRanderTray
Mickey wrote: > There is no Folder View settings in this version of KDE. What are you looking for exactly? (and where did you look expecting to find it)? -- Rex -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Latest systemd news
On Sat, 15 Nov 2014 08:53:59 -0500 Sam Varshavchik wrote: > Making the rounds of various technical mailing lists yesterday, with a > subject that's typically a variation of "Just for yucks, and giggles" isa > link to a commit to systemd's git, adding DNS caching to systemd; in one, > huge 857 line glop. Here's its entire commit message: "resolved: add DNS > cache". > > And, it's beauty to read. Made me teary-eyed to know that systemd will ca > che my DNS queries. Not sure why systemd, all of a sudden, needs to make DNS > queries. But if it does, it's going to cache them now! Such a sight to behold > makes my heart skip a beat: now, not just bind, or pretty much eve > ry DNS server that automatically caches DNS for you – but so will sy > stemd! > > But, seriously folks, systemd's DNS caching achieves absolutely 100% nothing. > Really. Surprised? Well, you'll be shocked to know that the DNS server that > systemd queries for that DNS RR, such as the stock "bind", already > automatically caches all recursive DNS replies!! systemd's own caching > produces absolutely zero useful results. On the oft chance that i > t sends a query for a non-cached RR, the local DNS server will cache the > response, before returning it to systemd, and then use the cached respons > e for all future queries. That's what DNS servers do: provide caching for > local clients. It's inherent in DNS's design: DNS was explicitly designedto > use aggressive caching, it's an internet-wide, distributed, locally cache > d database. > > Isn't modern technology amazing? > > I'm willing to consider the possibility that I missed something obvious, some > obvious value-added result from caching DNS RRs directly by systemd, and I'll > stick around for someone to enlighten me; or if Occam's razor applies, and > the author of that commit had no idea that bind already automatically caches > DNS responses, and, more importantly, that its cachi > ng algorithms are a result of painful lessons learned from various DNS cache > poisoning attacks, that have circulated around the intertubes, for the la > st couple of years. > > The only possible use case for this kind of caching approach would be if: > > A) You do not have a local DNS server nearby; and you have non-negligible > latencies to whatever DNS server you use. > > B) Your queries tend to be for domains that your DNS servers are not > authoritative for, so they'll benefit from local caching. > > So, can someone explain to me how likely this is going to be the case ina > typical deployment scenario that systemd is targeted for; in an average > corporate environment where systemd's alleged benefits will supposedly sh > ine? > > I would guess that a typical systemd deployment, in a corporate/business > environment, will certainly have multiple, low-latency DNS servers nearby > , won't that be the case? And, if so, then this is just another potentially > exploitable security hole in systemd, nothing more. > > P.S. After I wrote the above, poking around, Google dumped this onto my > screen: > > http://seclists.org/oss-sec/2014/q4/592 > > Mental note to myself: go back and check the timestamp of the systemd git > commit – before, or after, this was disclosed… > When will be the kernel embeded in the systemd? BR, Bob -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: NFS mount +
On 11/15/14 07:56, poma wrote: On 15.11.2014 11:07, poma wrote: Chapter 8. Network File System (NFS) https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-nfs.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Storage_Administration_Guide/Red_Hat_Enterprise_Linux-7-Storage_Administration_Guide-en-US.pdf#__WKANCHOR_46 4.5. Using Firewalls 4.5.1. Introduction to firewalld https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Security_Guide/Red_Hat_Enterprise_Linux-7-Security_Guide-en-US.pdf#__WKANCHOR_7a Wow, so much to know! I'm making progress, slowly but surely. Loaded one file on the server ,,, Thanks for the references, I need them, Bob -- http://www.qrz.com/db/W2BOD box10 Fedora-20/64bit Linux/XFCE -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Latest systemd news
Making the rounds of various technical mailing lists yesterday, with a subject that's typically a variation of "Just for yucks, and giggles" is a link to a commit to systemd's git, adding DNS caching to systemd; in one, huge 857 line glop. Here's its entire commit message: "resolved: add DNS cache". And, it's beauty to read. Made me teary-eyed to know that systemd will cache my DNS queries. Not sure why systemd, all of a sudden, needs to make DNS queries. But if it does, it's going to cache them now! Such a sight to behold makes my heart skip a beat: now, not just bind, or pretty much every DNS server that automatically caches DNS for you – but so will systemd! But, seriously folks, systemd's DNS caching achieves absolutely 100% nothing. Really. Surprised? Well, you'll be shocked to know that the DNS server that systemd queries for that DNS RR, such as the stock "bind", already automatically caches all recursive DNS replies!! systemd's own caching produces absolutely zero useful results. On the oft chance that it sends a query for a non-cached RR, the local DNS server will cache the response, before returning it to systemd, and then use the cached response for all future queries. That's what DNS servers do: provide caching for local clients. It's inherent in DNS's design: DNS was explicitly designed to use aggressive caching, it's an internet-wide, distributed, locally cached database. Isn't modern technology amazing? I'm willing to consider the possibility that I missed something obvious, some obvious value-added result from caching DNS RRs directly by systemd, and I'll stick around for someone to enlighten me; or if Occam's razor applies, and the author of that commit had no idea that bind already automatically caches DNS responses, and, more importantly, that its caching algorithms are a result of painful lessons learned from various DNS cache poisoning attacks, that have circulated around the intertubes, for the last couple of years. The only possible use case for this kind of caching approach would be if: A) You do not have a local DNS server nearby; and you have non-negligible latencies to whatever DNS server you use. B) Your queries tend to be for domains that your DNS servers are not authoritative for, so they'll benefit from local caching. So, can someone explain to me how likely this is going to be the case in a typical deployment scenario that systemd is targeted for; in an average corporate environment where systemd's alleged benefits will supposedly shine? I would guess that a typical systemd deployment, in a corporate/business environment, will certainly have multiple, low-latency DNS servers nearby, won't that be the case? And, if so, then this is just another potentially exploitable security hole in systemd, nothing more. P.S. After I wrote the above, poking around, Google dumped this onto my screen: http://seclists.org/oss-sec/2014/q4/592 Mental note to myself: go back and check the timestamp of the systemd git commit – before, or after, this was disclosed… pgpcsGrNmBBmO.pgp Description: PGP signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: NFS mount +
On 15.11.2014 11:07, poma wrote: > > Chapter 8. Network File System (NFS) > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-nfs.html > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Storage_Administration_Guide/Red_Hat_Enterprise_Linux-7-Storage_Administration_Guide-en-US.pdf#__WKANCHOR_46 > 4.5. Using Firewalls 4.5.1. Introduction to firewalld https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Security_Guide/Red_Hat_Enterprise_Linux-7-Security_Guide-en-US.pdf#__WKANCHOR_7a -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: NFS mount -
On 11/15/14 05:05, Tom H wrote: This is the problem. You have firewalld running and aren't allowing the nfs ports through. I have no idea how to whitelist a port with firewalld but there've been recent instructions on this list. I had tested with systemctl stop iptables and that did not help. This computer does run the firewalld and works fine with the other NFS server. Running systemctl stop firewalld on the server allows me to mount it from this computer which runs firewalld as originally installed with F-20. But you are right, firewalld seems to be preventing the mount. I will go from there ... Right now it's time to go out in the cold and feed my horses. Thank you much for the help, Bob -- http://www.qrz.com/db/W2BOD box10 Fedora-20/64bit Linux/XFCE -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: NFS mount +
Chapter 8. Network File System (NFS) https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-nfs.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Storage_Administration_Guide/Red_Hat_Enterprise_Linux-7-Storage_Administration_Guide-en-US.pdf#__WKANCHOR_46 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: NFS mount -
On Sat, Nov 15, 2014 at 4:04 AM, Bob Goodwin - Zuni, Virginia, USA wrote: > On 11/15/14 02:22, Tom H wrote: >> On Fri, Nov 14, 2014 at 3:12 PM, Bob Goodwin - Zuni, Virginia, USA >> wrote: >> On the server, what's the output of: >> >> systemctl status nfs* > > [root@box48 ~]# systemctl status nfs* > nfs\x2a.service >Loaded: not-found (Reason: No such file or directory) >Active: inactive (dead) >> >> systemctl status rpc* > > [root@box48 ~]# systemctl status rpc* > rpc\x2a.service >Loaded: not-found (Reason: No such file or directory) >Active: inactive (dead) >> >> systemctl status var*.mount > > [root@box48 ~]# systemctl status var*.mount > var\x2a.mount >Loaded: not-found (Reason: No such file or directory) >Active: inactive (dead) Sorry. I guess that this doen't work with v208 and that I must've been spoiled by Ubuntu's v215 and F21's v216. So you'd have to check the nfs-utils units without wildcards. Anyway, given the below it doesn't matter. >> exportfs > > [root@box48 ~]# exportfs > /nfs4exports 192.168.1.0/24 > /nfs4exports/data > 192.168.1.0/24 > /nfs4exports/home > 192.168.1.0/24 >> >> rpcinfo -p > > [root@box48 ~]# rpcinfo -p >program vers proto port service > 104 tcp111 portmapper > ... > 1000241 udp 59970 status > 1000241 tcp 48757 status > ... > 153 tcp 20048 mountd > ... > 134 tcp 2049 nfs > ... > 1000214 tcp 58822 nlockmgr > ... > 1000112 tcp875 rquotad nfs is up and running and the shares are exported. >> iptables -nL (or iptables -S) > > [root@box48 ~]# iptables -S > This is the problem. You have firewalld running and aren't allowing the nfs ports through. I have no idea how to whitelist a port with firewalld but there've been recent instructions on this list. The "difficulty" with nfs is that if you want to run nfsv4 only, you have to open 2049 and 111 (or even simply 2049 but won't be able to run "rpcinfo -p nfs_server" from a client) but if you want to use nfsv3, you have to set fixed ports in "/etc/sysconfig/nfs" (LOCKD_TCPPORT, LOCKD_UDPPORT, RPCMOUNTDOPTS, STATDARG). -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: NFS mount -
On 11/15/14 02:22, Tom H wrote: On the server, what's the output of: systemctl status nfs* But I do see the following: [root@box48 ~]# systemctl status /nfs4exports/data nfs4exports-data.mount - /nfs4exports/data Loaded: loaded (/etc/fstab) Active: active (mounted) since Fri 2014-11-14 17:29:45 EST; 10h ago Where: /nfs4exports/data What: /dev/sdb1 Process: 542 ExecMount=/bin/mount /home/data /nfs4exports/data -t none -o rw,bind (code=exited, status=0/SUCCESS) Nov 14 17:29:45 box48 systemd[1]: Mounted /nfs4exports/data. [root@box48 ~]# systemctl status /nfs4exports/home nfs4exports-home.mount - /nfs4exports/home Loaded: loaded (/etc/fstab) Active: active (mounted) since Fri 2014-11-14 17:29:45 EST; 10h ago Where: /nfs4exports/home What: /dev/sdb1 Process: 539 ExecMount=/bin/mount /home/home /nfs4exports/home -t none -o rw,bind (code=exited, status=0/SUCCESS) Nov 14 17:29:45 box48 systemd[1]: Mounted /nfs4exports/home. systemctl status rpc* Nov 14 17:29:45 box48 systemd[1]: Mounted /nfs4exports/data. [root@box48 ~]# systemctl status rpc/nfs4exports rpc-nfs4exports.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) -- http://www.qrz.com/db/W2BOD box10 Fedora-20/64bit Linux/XFCE -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: NFS mount -
On 11/15/14 02:22, Tom H wrote: On Fri, Nov 14, 2014 at 3:12 PM, Bob Goodwin - Zuni, Virginia, USA wrote: I have a problem connecting this Fedora-20 computer with an NFS server. I have just set up the server on Scientific Linux 7. ":/mnt/nasdata"? Sorry, mistyped, an artifact from Freenas which I am replacing. On the server, what's the output of: systemctl status nfs* [root@box48 ~]# systemctl status nfs* nfs\x2a.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) systemctl status rpc* [root@box48 ~]# systemctl status rpc* rpc\x2a.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) systemctl status var*.mount [root@box48 ~]# systemctl status var*.mount var\x2a.mount Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) exportfs [root@box48 ~]# exportfs /nfs4exports 192.168.1.0/24 /nfs4exports/data 192.168.1.0/24 /nfs4exports/home 192.168.1.0/24 rpcinfo -p [root@box48 ~]# rpcinfo -p program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000241 udp 59970 status 1000241 tcp 48757 status 151 udp 20048 mountd 151 tcp 20048 mountd 152 udp 20048 mountd 152 tcp 20048 mountd 153 udp 20048 mountd 153 tcp 20048 mountd 133 tcp 2049 nfs 134 tcp 2049 nfs 1002273 tcp 2049 nfs_acl 133 udp 2049 nfs 134 udp 2049 nfs 1002273 udp 2049 nfs_acl 1000211 udp 44643 nlockmgr 1000213 udp 44643 nlockmgr 1000214 udp 44643 nlockmgr 1000211 tcp 58822 nlockmgr 1000213 tcp 58822 nlockmgr 1000214 tcp 58822 nlockmgr 1000111 udp875 rquotad 1000112 udp875 rquotad 1000111 tcp875 rquotad 1000112 tcp875 rquotad iptables -nL (or iptables -S) [root@box48 ~]# iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N FORWARD_IN_ZONES -N FORWARD_IN_ZONES_SOURCE -N FORWARD_OUT_ZONES -N FORWARD_OUT_ZONES_SOURCE -N FORWARD_direct -N FWDI_public -N FWDI_public_allow -N FWDI_public_deny -N FWDI_public_log -N FWDO_public -N FWDO_public_allow -N FWDO_public_deny -N FWDO_public_log -N INPUT_ZONES -N INPUT_ZONES_SOURCE -N INPUT_direct -N IN_public -N IN_public_allow -N IN_public_deny -N IN_public_log -N OUTPUT_direct -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -j INPUT_direct -A INPUT -j INPUT_ZONES_SOURCE -A INPUT -j INPUT_ZONES -A INPUT -p icmp -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i lo -j ACCEPT -A FORWARD -j FORWARD_direct -A FORWARD -j FORWARD_IN_ZONES_SOURCE -A FORWARD -j FORWARD_IN_ZONES -A FORWARD -j FORWARD_OUT_ZONES_SOURCE -A FORWARD -j FORWARD_OUT_ZONES -A FORWARD -p icmp -j ACCEPT -A FORWARD -j REJECT --reject-with icmp-host-prohibited -A OUTPUT -j OUTPUT_direct -A FORWARD_IN_ZONES -i enp2s0 -g FWDI_public -A FORWARD_IN_ZONES -g FWDI_public -A FORWARD_OUT_ZONES -o enp2s0 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FWDI_public -j FWDI_public_log -A FWDI_public -j FWDI_public_deny -A FWDI_public -j FWDI_public_allow -A FWDO_public -j FWDO_public_log -A FWDO_public -j FWDO_public_deny -A FWDO_public -j FWDO_public_allow -A INPUT_ZONES -i enp2s0 -g IN_public -A INPUT_ZONES -g IN_public -A IN_public -j IN_public_log -A IN_public -j IN_public_deny -A IN_public -j IN_public_allow -A IN_public_allow -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT Thanks for looking at this, Bob -- http://www.qrz.com/db/W2BOD box10 Fedora-20/64bit Linux/XFCE -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: NFS mount -
On 11/14/14 21:17, Joseph Loo wrote: can you ping the server from the client? Yes, ping, ssh, both work as expected: [bobg@box10 ~]$ ping -c 2 192.168.1.48 PING 192.168.1.48 (192.168.1.48) 56(84) bytes of data. 64 bytes from 192.168.1.48: icmp_seq=1 ttl=64 time=0.295 ms 64 bytes from 192.168.1.48: icmp_seq=2 ttl=64 time=0.208 ms --- 192.168.1.48 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.208/0.251/0.295/0.046 ms -- http://www.qrz.com/db/W2BOD box10 Fedora-20/64bit Linux/XFCE -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
