[opensuse] nfs fails to start
Tumbleweed kernel-desktop-3.14.1-24.2.geafcebd.x86_64 Had to reboot last night and cannot start nfs :^( systemctl status nfs nfs.service - LSB: NFS client services Loaded: loaded (/etc/init.d/nfs) Drop-In: /run/systemd/generator/nfs.service.d └─50-insserv.conf-$remote_fs.conf Active: failed (Result: timeout) since Tue 2014-04-22 10:40:42 EDT; 8min ago Process: 15602 ExecStart=/etc/init.d/nfs start (code=killed, signal=TERM) Apr 22 10:39:14 Crash nfs[15602]: mount.nfs: mount options: "rw,bg,retry=5,_netdev" Apr 22 10:40:42 Crash systemd[1]: nfs.service operation timed out. Terminating. Apr 22 10:40:42 Crash systemd[1]: Failed to start LSB: NFS client services. Apr 22 10:40:42 Crash systemd[1]: Unit nfs.service entered failed state. Apr 22 10:43:28 Crash mount[16304]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:43:28 Crash mount[16303]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:43:28 Crash mount[16305]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:47:43 Crash mount[17037]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:47:43 Crash mount[17038]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:47:43 Crash mount[17041]: mount to NFS server '192.168.1.3' failed: timed out, retrying stopped nfs restarted rpcbind restarted nfs still failed rpcbind is active/running suggestions? tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/22/2014 04:53 PM, Patrick Shanahan wrote:
Apr 22 10:39:14 Crash nfs[15602]: mount.nfs: mount options: "rw,bg,retry=5,_netdev" Apr 22 10:40:42 Crash systemd[1]: nfs.service operation timed out. Terminating. Apr 22 10:40:42 Crash systemd[1]: Failed to start LSB: NFS client services. Apr 22 10:40:42 Crash systemd[1]: Unit nfs.service entered failed state. Apr 22 10:43:28 Crash mount[16304]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:43:28 Crash mount[16303]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:43:28 Crash mount[16305]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:47:43 Crash mount[17037]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:47:43 Crash mount[17038]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:47:43 Crash mount[17041]: mount to NFS server '192.168.1.3' failed: timed out, retrying
Did the NFS server on 192.168.1.3 also die? Are the services needed by NFS running? $ /usr/sbin/rpcinfo -p 192.168.1.3 What shares does it export? $ /usr/sbin/showmount -e 192.168.1.3 Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Bernhard Voelker <mail@bernhard-voelker.de> [04-22-14 11:11]:
On 04/22/2014 04:53 PM, Patrick Shanahan wrote:
Apr 22 10:39:14 Crash nfs[15602]: mount.nfs: mount options: "rw,bg,retry=5,_netdev" Apr 22 10:40:42 Crash systemd[1]: nfs.service operation timed out. Terminating. Apr 22 10:40:42 Crash systemd[1]: Failed to start LSB: NFS client services. Apr 22 10:40:42 Crash systemd[1]: Unit nfs.service entered failed state. Apr 22 10:43:28 Crash mount[16304]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:43:28 Crash mount[16303]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:43:28 Crash mount[16305]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:47:43 Crash mount[17037]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:47:43 Crash mount[17038]: mount to NFS server '192.168.1.3' failed: timed out, retrying Apr 22 10:47:43 Crash mount[17041]: mount to NFS server '192.168.1.3' failed: timed out, retrying
Did the NFS server on 192.168.1.3 also die?
yes but restarted and reports active/running
Are the services needed by NFS running?
$ /usr/sbin/rpcinfo -p 192.168.1.3
rpcinfo -p 192.168.1.3 rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out
What shares does it export?
on 192.168.1.3, exportfs: / <world> /mnt/ExTernal <world> /mnt/photos <world> /var <world> /srv <world> /mnt/g7_unk3 <world> /home <world>
$ /usr/sbin/showmount -e 192.168.1.3
showmount -e 192.168.1.3 clnt_create: RPC: Port mapper failure - Timed out Ok, appears there is more info but it means ?? to me :^( tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/22/2014 05:38 PM, Patrick Shanahan wrote:
rpcinfo -p 192.168.1.3 rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out
showmount -e 192.168.1.3 clnt_create: RPC: Port mapper failure - Timed out
Both timed out, i.e. there is a networking problem - as Anton already suspected. Use a TCP-traceroute to the portmapper (111) to see where it's blocked: $ traceroute --tcp -p 111 192.168.1.3 Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Bernhard Voelker <mail@bernhard-voelker.de> [04-22-14 12:02]:
On 04/22/2014 05:38 PM, Patrick Shanahan wrote:
rpcinfo -p 192.168.1.3 rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out
showmount -e 192.168.1.3 clnt_create: RPC: Port mapper failure - Timed out
Both timed out, i.e. there is a networking problem - as Anton already suspected.
Use a TCP-traceroute to the portmapper (111) to see where it's blocked:
$ traceroute --tcp -p 111 192.168.1.3
Well, since I stopped the server firewall, restart nfs, mounted the shares from remote and restarted the firewall, there is no failure. But I will retain this and if it happens again, try. What I do not understand is how stopping the firewall and then restarting it does not destroy the connection as it apparently thought it was originally supposed to do. And no changes have been made to the server in between nfs working and it not :^( ??? puzzled. tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/22/2014 06:31 PM, Patrick Shanahan wrote:
Well, since I stopped the server firewall, restart nfs, mounted the shares from remote and restarted the firewall, there is no failure. But I will retain this and if it happens again, try.
What I do not understand is how stopping the firewall and then restarting it does not destroy the connection as it apparently thought it was originally supposed to do. And no changes have been made to the server in between nfs working and it not :^( ??? puzzled.
I'm no NFS expert, but as far as I understand "mount -t nfs ..." first tries to resolve the NFS service on the server side by contacting the portmapper. Therefore my (wild) guess is that only NFS is configured in the firewall, but the portmapper is blocked. Once the connection is up, the portmapper is not needed anymore, and you could start the firewall ... and NFS would still be working. Just a guess. BTW: you can consult your firewall logs - there should be an entry about an connecting attempt to port 111 being blocked. BTW2: there may even be 2 (or more) firewalls be involved, of course ... Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Bernhard Voelker <mail@bernhard-voelker.de> [04-22-14 13:47]:
On 04/22/2014 06:31 PM, Patrick Shanahan wrote:
Well, since I stopped the server firewall, restart nfs, mounted the shares from remote and restarted the firewall, there is no failure. But I will retain this and if it happens again, try.
What I do not understand is how stopping the firewall and then restarting it does not destroy the connection as it apparently thought it was originally supposed to do. And no changes have been made to the server in between nfs working and it not :^( ??? puzzled.
I'm no NFS expert, but as far as I understand "mount -t nfs ..." first tries to resolve the NFS service on the server side by contacting the portmapper. Therefore my (wild) guess is that only NFS is configured in the firewall, but the portmapper is blocked. Once the connection is up, the portmapper is not needed anymore, and you could start the firewall ... and NFS would still be working. Just a guess.
BTW: you can consult your firewall logs - there should be an entry about an connecting attempt to port 111 being blocked.
BTW2: there may even be 2 (or more) firewalls be involved, of course ...
In "BTW2", disabling *one* and suceeding would appear to disprove? Firewall logs from the server show access from 192.168.1.10 on dpt=111 to 192.168.1.3 dropped until I stopped the firewall and accessed the shares. Upon restarting the firewall access is allowed ??? No other changes were made on the server, 192.168.1.3, before or after problem occurred. tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/22/2014 12:31 PM, Patrick Shanahan wrote:
What I do not understand is how stopping the firewall and then restarting it does not destroy the connection as it apparently thought it was originally supposed to do.
That bothers me as a well There could be a security hole sitting there. -- December 32, 1999: We're pleased to report no Y2K failures! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 4/22/2014 1:41 PM, Anton Aylward wrote:
On 04/22/2014 12:31 PM, Patrick Shanahan wrote:
What I do not understand is how stopping the firewall and then restarting it does not destroy the connection as it apparently thought it was originally supposed to do.
That bothers me as a well There could be a security hole sitting there.
Firewalls usually do not disrupt pre-existing connections/sockets. Removing the firewall, simply allows the source and destination to continue unhindered. Reestablishing the firewall, and that same stream is allowed because it meets the rules. A simple firewall is distinct from a router. But even most iptables based router implementations would allow established connections to continue. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/22/2014 05:15 PM, John Andersen wrote:
On 4/22/2014 1:41 PM, Anton Aylward wrote:
On 04/22/2014 12:31 PM, Patrick Shanahan wrote:
What I do not understand is how stopping the firewall and then restarting it does not destroy the connection as it apparently thought it was originally supposed to do.
That bothers me as a well There could be a security hole sitting there.
Firewalls usually do not disrupt pre-existing connections/sockets.
Removing the firewall, simply allows the source and destination to continue unhindered. Reestablishing the firewall, and that same stream is allowed because it meets the rules.
That seems reasonable, but its not what is implied here. Do we agree that if the rules do not permit it, then a connection that was set up before the firewall started should be torn down when the firewall starts? Do we agree that if it is permitted to stay up then THAT is a security violation? Good. Now what Patrick had was a situation where the firewall was up and the connection could not be established. The firewall goes down and he can establish the connection. To me, that implies the firewall was blocking the connection. Why should it do that unless there is a rule to that effect? And if there is a rule to that effect then it comes into action when the firewall is brought up and should tear down any connection that violates the rule. The connection could not be established while the firewall was up? Why? Because it violated some rule. I agree with you when you say:
Re-establishing the firewall, and that same stream is allowed because it meets the rules.
My point is that if it meets the rule then there would have been no problem setting it up while the firewall was active. Now I don't have access to to Patrick's logs, so maybe something else is going on, but one interpretation of what *has* been reported is that the firewall allows established connections to continue though they don't meet the rules. If that is the case then there is a security problem. I agree with you, John, about what firewalls OUGHT to do. I am concerned about the evidence as to what this firewall *IS* doing.
A simple firewall is distinct from a router.
But even most iptables based router implementations would allow established connections to continue.
So, you are saying that they would allow established connections to continue EVEN IF THEY ARE IN VIOLATION OF THE RULES? Is that the way iptables works? -- The master worries about the work, and the apprentice worries about the tools. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward <opensuse@antonaylward.com> [04-22-14 17:32]: [...]
Now I don't have access to to Patrick's logs, so maybe something else is going on, but one interpretation of what *has* been reported is that the firewall allows established connections to continue though they don't meet the rules. If that is the case then there is a security problem.
From the server, 192.168.1.3 egrep 192.168.1.10.*111 /var/log/firewall
http://wahoo.no-ip.org/~pat/firewall.log.txt What "rules" are of interest and how to show them?
I agree with you, John, about what firewalls OUGHT to do. I am concerned about the evidence as to what this firewall *IS* doing.
interesting :^) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Tue, 22 Apr 2014, Patrick Shanahan wrote:
From the server, 192.168.1.3 egrep 192.168.1.10.*111 /var/log/firewall
I notice that the failed attempts were when the client (.10) used priviledged ports (under 1024) as source-ports. When it worked, unpriviledged ports were used.
What "rules" are of interest and how to show them?
Those on both machines from: iptables -vL input_int | egrep 'nfs|rpc' iptables -vL output_int | egrep 'nfs|rpc' iptables -vL input_ext | egrep 'nfs|rpc' iptables -vL output_ext | egrep 'nfs|rpc' -dnh -- [Malaysia is] a weird place, 'your alien planet should feel more peculiar than Kuala Lumpur' is a test few SF-writers pass. -- Thomas Womack -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* David Haller <dnh@opensuse.org> [04-24-14 02:51]:
Hello,
On Tue, 22 Apr 2014, Patrick Shanahan wrote:
From the server, 192.168.1.3 egrep 192.168.1.10.*111 /var/log/firewall
I notice that the failed attempts were when the client (.10) used priviledged ports (under 1024) as source-ports. When it worked, unpriviledged ports were used.
What "rules" are of interest and how to show them?
Those on both machines from:
iptables -vL input_int | egrep 'nfs|rpc'
server: 192.168.1.3 iptables: No chain/target/match by that name. client: 192.168.1.10 iptables: No chain/target/match by that name.
iptables -vL output_int | egrep 'nfs|rpc'
server: iptables: No chain/target/match by that name. client: iptables: No chain/target/match by that name.
iptables -vL input_ext | egrep 'nfs|rpc'
server: 0 0 LOG udp -- any any anywhere anywhere limit: avg 3/min burst 5 ctstate NEW udp dpt:sunrpc LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:sunrpc 0 0 LOG tcp -- any any anywhere anywhere limit: avg 3/min burst 5 ctstate NEW tcp dpt:sunrpc LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:sunrpc 0 0 LOG udp -- any any anywhere anywhere limit: avg 3/min burst 5 ctstate NEW udp dpt:nfs LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:nfs 0 0 LOG tcp -- any any anywhere anywhere limit: avg 3/min burst 5 ctstate NEW tcp dpt:nfs LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:nfs 0 0 LOG tcp -- any any anywhere anywhere limit: avg 3/min burst 5 ctstate NEW tcp dpt:nfs LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:nfs client: 0 0 LOG udp -- any any anywhere anywhere ctstate NEW udp dpt:sunrpc LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:sunrpc 0 0 LOG tcp -- any any anywhere anywhere ctstate NEW tcp dpt:sunrpc LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:sunrpc 0 0 LOG udp -- any any anywhere anywhere ctstate NEW udp dpt:nfs LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:nfs 0 0 LOG tcp -- any any anywhere anywhere ctstate NEW tcp dpt:nfs LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:nfs 0 0 LOG tcp -- any any anywhere anywhere ctstate NEW tcp dpt:nfs LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:nfs 0 0 LOG tcp -- any any anywhere anywhere ctstate NEW tcp dpt:nfs LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:nfs
iptables -vL output_ext | egrep 'nfs|rpc'
server: 0 0 LOG udp -- any any anywhere anywhere limit: avg 3/min burst 5 ctstate NEW udp dpt:sunrpc LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:sunrpc 0 0 LOG tcp -- any any anywhere anywhere limit: avg 3/min burst 5 ctstate NEW tcp dpt:sunrpc LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:sunrpc 0 0 LOG udp -- any any anywhere anywhere limit: avg 3/min burst 5 ctstate NEW udp dpt:nfs LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:nfs 0 0 LOG tcp -- any any anywhere anywhere limit: avg 3/min burst 5 ctstate NEW tcp dpt:nfs LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:nfs 0 0 LOG tcp -- any any anywhere anywhere limit: avg 3/min burst 5 ctstate NEW tcp dpt:nfs LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-RPC " 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:nfs client: iptables: No chain/target/match by that name. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 4/22/2014 2:28 PM, Anton Aylward wrote:
That seems reasonable, but its not what is implied here.
Do we agree that if the rules do not permit it, then a connection that was set up before the firewall started should be torn down when the firewall starts? Do we agree that if it is permitted to stay up then THAT is a security violation?
The security violation you postulate was letting a connection happen BEFORE you launched your firewall. In the several implementations of netfilter firewalls that I have used, they are only aware of allowing/denying the creation of new connections, and do not *typically* mess with pre-existing open connection/sockets. I think there are ways to force netfilter to close all open open connections but this could be more than a little disruptive. (lots of internal connections exist through netfilter too). So while I think you COULD force pre-existing to be torn down, I haven't spent enough time thinking of all the ramifications of that yet to fully agree that they SHOULD. In any event, I don't think that is how most such firewalls work. SO:.... When you turn the firewall off, everything reverts to the state where IF there is something LISTENING on that port, then that port is "Open" and it can accept connections. If you intend to accept many connections, the first thing your listening daemon does after a connection is get the hell off of the listening port. You do this via ACCEPT. See: man 2 accept You issue an ACCEPT and that gives you a new socket (file descriptor in *nix), which is *no longer in the listening state*, (its in the connected state). Netfilter Firewalls usually watch ports and trap the connection attempts. Most don't watch every packet on established connections. Too much Overhead. So when Patrick tears down a firewall, makes a connection, then brings up the firewall it typically does not know about pre-existing connections, they are by design, in a separate address space This is why you start your firewall to tell iptables to configure netfilter before you start your listening daemons, so that the script kiddie hammering a port can't get accepted by a daemon that started before netfilter. Not knowing about pre-existing connections is a good thing in most cases. You can ssh into a remote server, dick around with the firewall settings and stop/restart it without worrying about killing your own ssh connection, and potentially leaving your remote machine in a broken and vulnerable state. That original connection will persist. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/22/2014 06:38 PM, John Andersen wrote:
The security violation you postulate was letting a connection happen BEFORE you launched your firewall.
NO! The security violation I postulated involved the firewall being down FOR ANY REASON. Lets leave aside misconfiguration ... In Patrick's case we have an example of the generic Something isn't working... I wonder if the firewall is in the way.... Lets take it down for a while and experiment... Patrick remembered to put it back up PROMPTLY, but we don't know what the critical aperture is. I've read that newly installed Windows machines on the 'Net can be hacked in a couple of minutes between being connected and firewall software being installed/configured. My POV is that security rule is a security rule. If the firewall rules prohibit a connection then they should ensure that connection does not exist as opposed to merely 'cannot be initiated'. I understand the explanation you give and don't disagree with it. Yes you have explained what is going on. I think you are quite correct.
You can ssh into a remote server, dick around with the firewall settings and stop/restart it without worrying about killing your own ssh connection, and potentially leaving your remote machine in a broken and vulnerable state. That original connection will persist.
I don't see the problem. The rules permit a ssh connection. My 'proposed' idea about tearing down connections that violate the rules would allow this connection because the rules permit it. I'm NOT saying that starting the firewall should tear down all connections. I'm talking about connections that the firewall would otherwise prohibit. A few years ago, not long after AIX was released, I had an argument with a senior executive at IBM. My attitude towards security configuration lies on the side of "everything that is not explicitly allowed is prohibited". I held that all the services that inetd, for example, supported should be default off. He insisted that the way AIX was then shipped with most of them default on was correct, and that it was the sysadmins responsibility to determine what needed to be turned off for security purposes. I had seen too many novice admins who didn't know enough about security, never mind fringes of security that hackers exploit, which is why I had come to adopt the 'everything off' stance. If the users needed it they would demand it and it could be turned on. There are services such as tftp that are fringe/specialized yet offer entrances to hackers, and I can see no reason to ship them default on. In the long run I feel justified; most of the systems I deal with now - Linux, AIX and other non-Windows systems - are shipped 'default off' for many facilities, especially inetd and xinetd. We can't expect sysadmins to be aware of every security hole that might be generated. We need to have aggressive defaults. Yes, I realise that many of these will require, no will DEMAND more vigilance on the part of the people building the isntllation kits. We've recently had a discussion of Apparmor and Dovecot and I think that's a good posterboy. Installing Dovecot _should_ include installing the Apparmor rules that allow it to be run. Heck, installing it bring in the relevant PAM entries, doesn't it? -- "Realizing the importance of the case, my men are rounding up twice the number of usual suspects" -- Cpt Renault to Major Strasser, Cassablanaca -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward <opensuse@antonaylward.com> [04-22-14 19:11]: [...]
In Patrick's case we have an example of the generic
Something isn't working... I wonder if the firewall is in the way.... Lets take it down for a while and experiment...
Patrick remembered to put it back up PROMPTLY, but we don't know what the critical aperture is.
I've read that newly installed Windows machines on the 'Net can be hacked in a couple of minutes between being connected and firewall software being installed/configured.
More the point, I disconnected the modem/router while the firewall was down :^). Only security would be local/internal and I am in *complete* control there! And I only did the mechanical fix because it is much faster than reconfiguring the router to deny ALL outside. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/22/2014 07:16 PM, Patrick Shanahan wrote:
* Anton Aylward <opensuse@antonaylward.com> [04-22-14 19:11]: [...]
In Patrick's case we have an example of the generic
Something isn't working... I wonder if the firewall is in the way.... Lets take it down for a while and experiment...
Patrick remembered to put it back up PROMPTLY, but we don't know what the critical aperture is.
I've read that newly installed Windows machines on the 'Net can be hacked in a couple of minutes between being connected and firewall software being installed/configured.
More the point, I disconnected the modem/router while the firewall was down :^). Only security would be local/internal and I am in *complete* control there!
And I only did the mechanical fix because it is much faster than reconfiguring the router to deny ALL outside.
God security practice never the less :-) -- No one who's seen it in action can say the phrase "government help" without either laughing or crying. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 4/22/2014 4:09 PM, Anton Aylward wrote:
You can ssh into a remote server, dick around with the firewall settings and stop/restart it without worrying about killing your own ssh connection, and potentially leaving your remote machine in a broken and vulnerable state. That original connection will persist.
I don't see the problem. The rules permit a ssh connection. My 'proposed' idea about tearing down connections that violate the rules would allow this connection because the rules permit it.
Ah, I see. You're obviously one of those guys who never makes an error! ;-) Me? I fuckup all the time. I accidentally get my Nics mixed up, deny inbound ssh, make typos that leave everything blocked, or nothing at all blocked, etc. If rolling the firewall killed existing connections there has been more than one occurrence where I would be buying an airline ticket to some remote bush Alaskan village just to reboot the data collection server in the sewage plant or some such, all because of some stupid typo. I've learned to always leave that SSH session live and test new sessions before I tear it down.
I'm NOT saying that starting the firewall should tear down all connections. I'm talking about connections that the firewall would otherwise prohibit.
Yeah, I understand. Give it a few weeks and SystemD will probably take over that too, but in the meantime netfilter doesn't know about those open connections, and making it do so, may open as many security holes as it closes. Patrick's assumption that a *pre-existing* connection should be stopped by a new firewall rule is simply not the case today, but it is a common misconception. So much so that it is FAQ Question 4B in the Shorewall Firewall guide. http://shorewall.net/3.0/FAQ.htm#faq4b Patrick should test by restarting NFS, not *just* restarting the firewall. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/22/2014 07:36 PM, John Andersen wrote:
On 4/22/2014 4:09 PM, Anton Aylward wrote:
You can ssh into a remote server, dick around with the firewall settings and stop/restart it without worrying about killing your own ssh connection, and potentially leaving your remote machine in a broken and vulnerable state. That original connection will persist.
I don't see the problem. The rules permit a ssh connection. My 'proposed' idea about tearing down connections that violate the rules would allow this connection because the rules permit it.
Ah, I see. You're obviously one of those guys who never makes an error! ;-) Me? I fuckup all the time. I accidentally get my Nics mixed up, deny inbound ssh, make typos that leave everything blocked, or nothing at all blocked, etc.
I'm a belt and braces and rivets and measure twice before deciding not to cut today but think about it overnight type of guy. I once referred t myself as a 'paid to be paranoid' type of sysadmin and was taken to task for that, being told that paranoia is an illness and not a security stance. I try very very had to make sure my errors are (a) low impact and (b) reversible. Just don't mention that to SheWhoSallNotBeNamed, please.
I'm NOT saying that starting the firewall should tear down all connections. I'm talking about connections that the firewall would otherwise prohibit.
Yeah, I understand. Give it a few weeks and SystemD will probably take over that too, but in the meantime netfilter doesn't know about those open connections, and making it do so, may open as many security holes as it closes.
Patrick's assumption that a *pre-existing* connection should be stopped by a new firewall rule is simply not the case today, but it is a common misconception. So much so that it is FAQ Question 4B in the Shorewall Firewall guide. http://shorewall.net/3.0/FAQ.htm#faq4b
Indeed. As you point out, that is the way iptables has been set up to work. I'm not saying that is not how things work; I'm just saying that, rightly or wrongly, there is a potential security risk. Patrick's strategy of disconnecting the router was one very effective way of mitigating that risk. Could iptables be set up so that a firewall will tear down an existing connection that violates its rules? I have no doubt it could. The way things work not seem to be a well established convention, sort of like what side of the road to drive on. So long as everyone follows the same convention we have a predictable behaviour. The 'logical' argument that we should drive on the let in the northern hemisphere and on the right in the southern so as to counteract the natural spin of tornadoes is totally beside the point: like in RubyonRails, convention trumps everything. I think Patrick is eminently sensible. A simple and effective solution. He's obviously one of us 'security paranoid' types. -- intaxification (n): Euphoria at getting a tax refund, which lasts until you realize it was your money to start with. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-04-23 02:42, Anton Aylward wrote:
On 04/22/2014 07:36 PM, John Andersen wrote:
Patrick's assumption that a *pre-existing* connection should be stopped by a new firewall rule is simply not the case today, but it is a common misconception. So much so that it is FAQ Question 4B in the Shorewall Firewall guide. http://shorewall.net/3.0/FAQ.htm#faq4b
Indeed. As you point out, that is the way iptables has been set up to work. I'm not saying that is not how things work; I'm just saying that, rightly or wrongly, there is a potential security risk.
Patrick's strategy of disconnecting the router was one very effective way of mitigating that risk.
Could iptables be set up so that a firewall will tear down an existing connection that violates its rules? I have no doubt it could.
I doubt it could :-) For instance, some connections, like ftp and nfs, in different manners, need a port negotiation, and authorize that random port dynamically for the service to establish. When the firewall starts and there is already an ftp or nfs connection it can not know which are the authorized extra ports, because while it was off, it could not track connections. In that scenario, established and allowed nfs connections would be teared down on firewall start. However, I have seen a configuration somewhere that tearing down the firewall also tears down the network. All existing connections, good or bad, are broken. Means no remote maintenance, of course. More sensible is not allowing any new connection while the firewall is been restarted. I think that SuSEfirewall can do this, but I don't remember how (does it do it by default?). Done this way, unplugging the router is not necessary - but peace of mind is a good thing ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
* John Andersen <jsamyth@gmail.com> [04-22-14 19:38]: [...]
Patrick's assumption that a *pre-existing* connection should be stopped by a new firewall rule is simply not the case today, but it is a common misconception. So much so that it is FAQ Question 4B in the Shorewall Firewall guide. http://shorewall.net/3.0/FAQ.htm#faq4b
Patrick should test by restarting NFS, not *just* restarting the firewall.
During an access lull, I restarted the server and the shared directories were automagically handled as expected. Manupilating the firewall was not necessary. # systemctl status nfs nfsserver nfs.service - LSB: NFS client services Loaded: loaded (/etc/init.d/nfs) Drop-In: /run/systemd/generator/nfs.service.d └─50-insserv.conf-$remote_fs.conf Active: active (running) since Tue 2014-04-22 20:38:49 EDT; 1h 46min ago Process: 2225 ExecStart=/etc/init.d/nfs start (code=exited, status=0/SUCCESS) CGroup: /system.slice/nfs.service ├─2267 /usr/sbin/rpc.gssd -D -p /var/lib/nfs/rpc_pipefs └─2283 /usr/sbin/rpc.idmapd -p /var/lib/nfs/rpc_pipefs Apr 22 20:45:02 wahoo rpc.gssd[2267]: ERROR: can't open /var/lib/nfs/rpc_pipefs/gssd/clntXX/info: No such file or directory Apr 22 20:45:02 wahoo rpc.gssd[2267]: ERROR: failed to read service info Apr 22 20:45:02 wahoo rpc.gssd[2267]: ERROR: can't open /var/lib/nfs/rpc_pipefs/gssd/clntXX/info: No such file or directory Apr 22 20:45:02 wahoo rpc.gssd[2267]: ERROR: failed to read service info Apr 22 20:45:02 wahoo rpc.gssd[2267]: ERROR: can't open /var/lib/nfs/rpc_pipefs/gssd/clntXX/info: No such file or directory Apr 22 20:45:02 wahoo rpc.gssd[2267]: ERROR: failed to read service info Apr 22 20:45:02 wahoo rpc.gssd[2267]: ERROR: can't open /var/lib/nfs/rpc_pipefs/gssd/clntXX/info: No such file or directory Apr 22 20:45:02 wahoo rpc.gssd[2267]: ERROR: failed to read service info Apr 22 20:45:02 wahoo rpc.gssd[2267]: ERROR: can't open /var/lib/nfs/rpc_pipefs/gssd/clntXX/info: No such file or directory Apr 22 20:45:02 wahoo rpc.gssd[2267]: ERROR: failed to read service info nfsserver.service - LSB: Start the kernel based NFS daemon Loaded: loaded (/etc/init.d/nfsserver) Active: active (running) since Tue 2014-04-22 20:38:49 EDT; 1h 46min ago Process: 2266 ExecStart=/etc/init.d/nfsserver start (code=exited, status=0/SUCCESS) CGroup: /system.slice/nfsserver.service ├─2315 /usr/sbin/rpc.mountd └─2319 /usr/sbin/rpc.statd --no-notify Apr 22 20:38:49 wahoo rpc.mountd[2315]: Version 1.2.8 starting Apr 22 20:38:49 wahoo rpc.statd[2319]: Version 1.2.8 starting Apr 22 20:38:49 wahoo rpc.statd[2319]: Flags: TI-RPC Apr 22 20:38:49 wahoo systemd[1]: Started LSB: Start the kernel based NFS daemon. I have no idea why the gssd errs as it is not configured in server or client..... go figure ????..... :^) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [04-22-14 22:32]: [...]
I have no idea why the gssd errs as it is not configured in server or client.....
go figure ????..... :^)
And indeed the server boot went quite well for the mechanics available: # systemd-analyze blame | head 13.800s mysql.service 11.422s apache2.service 11.340s spamd.service 10.699s SuSEfirewall2.service 8.863s plymouth-start.service 6.289s network.service 6.046s fail2ban.service 5.990s ntp.service 5.335s network@eth0.service 3.606s systemd-fsck@dev-system-var.service 01: None 00.0: 10102 Main Memory [Created at memory.66] Unique ID: rdCR.CxwsZFjVASF Hardware Class: memory Model: "Main Memory" Memory Range: 0x00000000-0xf7a7afff (rw) Memory Size: 3 GB + 768 MB Config Status: cfg=no, avail=yes, need=no, active=unknown 24: IDE 00.0: 10600 Disk Model: "ST3400633AS" Capacity: 372 GB (400088457216 bytes) 25: IDE 100.0: 10600 Disk Model: "ST3400633AS Capacity: 372 GB (400088457216 bytes) 26: IDE 200.0: 10600 Disk Model: "ST4000DM000-1F21" Capacity: 3726 GB (4000787030016 bytes) 27: IDE 401.0: 10600 Disk Model: "IBM-DJNA-352030" Capacity: 19 GB (20416757760 bytes) 28: IDE 600.0: 10600 Disk Model: "WDC WD1000BB-00C" Capacity: 93 GB (100030242816 bytes) 29: IDE 601.0: 10600 Disk Model: "WDC WD2500JB-00G" Capacity: 232 GB (250059350016 bytes) 30: IDE 700.0: 10600 Disk Model: "WDC WD2500JB-00G" Capacity: 232 GB (250059350016 bytes) 31: SCSI 800.0: 10600 Disk Model: "External AL25744_12345678" Device: usb 0xce14 "AL25744_12345678" Capacity: 1863 GB (2000409772544 bytes) and one which hwinfo doesn't show: Disk /dev/mapper/VGpix-photos: 4000.8 GB, 4000778813440 bytes, 7814021120 sectors 77: None 00.0: 10103 CPU [Created at cpu.446] Unique ID: rdCR.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "AuthenticAMD" Model: 15.43.1 "AMD Athlon(tm) 64 X2 Dual Core Processor 4200+" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,lm,3dnowext,3dnow,rep_good,nopl,pni,lahf_lm,cmp_legacy Clock: 2210 MHz BogoMips: 4420.14 Cache: 512 kb Units/Processor: 2 Config Status: cfg=no, avail=yes, need=no, active=unknown 78: None 01.0: 10103 CPU [Created at cpu.446] Unique ID: wkFv.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "AuthenticAMD" Model: 15.43.1 "AMD Athlon(tm) 64 X2 Dual Core Processor 4200+" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,lm,3dnowext,3dnow,rep_good,nopl,pni,lahf_lm,cmp_legacy Clock: 2210 MHz BogoMips: 4419.43 Cache: 512 kb Units/Processor: 2 Config Status: cfg=no, avail=yes, need=no, active=unknown The 4Tb drive must be mounted after boot as it is not recognized correctly during boot. Gleaned from conversation on opensuse-factory earlier this year. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-04-23 04:30, Patrick Shanahan wrote:
I have no idea why the gssd errs as it is not configured in server or client.....
I see those errors here, too. No idea what they are, things work. So far... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [04-24-14 07:49]:
On 2014-04-23 04:30, Patrick Shanahan wrote:
I have no idea why the gssd errs as it is not configured in server or client.....
I see those errors here, too. No idea what they are, things work. So far...
GSS is Global Security Services which are for nfs but for a secure local net, I cannot see a reason to employe them, nor a reason for error comments when they are not applied.... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/22/14 17:38, Patrick Shanahan wrote:
* Bernhard Voelker <mail@bernhard-voelker.de> [04-22-14 11:11]:
Are the services needed by NFS running?
$ /usr/sbin/rpcinfo -p 192.168.1.3
rpcinfo -p 192.168.1.3 rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out
In your first email you reported that rpcbind runs. If that happens again, try to restart rpcbind.socket, too. Maybe you need to stop rpcbind.socket, restart rpcbind.service, and start rpcbind.socket. I had this problem, too. My interim solution has been to stop and disable rpcbind.socket. In my setup, stuff works without systemd-socket-activated rpcbind, the daemon alone is sufficient. I don't know that the Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Joachim Schrod <jschrod@acm.org> [04-22-14 14:01]:
On 04/22/14 17:38, Patrick Shanahan wrote:
* Bernhard Voelker <mail@bernhard-voelker.de> [04-22-14 11:11]:
Are the services needed by NFS running?
$ /usr/sbin/rpcinfo -p 192.168.1.3
rpcinfo -p 192.168.1.3 rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out
In your first email you reported that rpcbind runs.
If that happens again, try to restart rpcbind.socket, too. Maybe you need to stop rpcbind.socket, restart rpcbind.service, and start rpcbind.socket.
I had this problem, too. My interim solution has been to stop and disable rpcbind.socket. In my setup, stuff works without systemd-socket-activated rpcbind, the daemon alone is sufficient.
I don't know that the
Tks, will keep this in mind, also. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/22/2014 10:53 AM, Patrick Shanahan wrote:
suggestions?
Ping remote host. Server running on remote host. Firewall open locally and remote "What has been changed?" Sometimes a reboot changes things without you knowing because you customized the 'live' system and the book lost all that. Mea cupla, that's particularly true of firewall settings! -- "The creative person is willing to live with ambiguity. He doesn't need problems solved immediately and can afford to wait for the right ideas." -- Abe Tannenbaum. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward <opensuse@antonaylward.com> [04-22-14 11:22]:
On 04/22/2014 10:53 AM, Patrick Shanahan wrote:
suggestions?
Ping remote host.
works
Server running on remote host.
yes
Firewall open locally and remote
yes
"What has been changed?"
latest change was kernel (2 days), but I *think* that that kernel was active and worked prior to *this* reboot.
Sometimes a reboot changes things without you knowing because you customized the 'live' system and the book lost all that. Mea cupla, that's particularly true of firewall settings!
Bingo. Stopped server firewall, issued mount -a, started nfs, started firewall and still have connection. But, "yast nfs" reports firewall port is open ??? And I made no firewall changes between boots ??? tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I don't believe any of my 13.2 installations fail to produce these messages on tty1 during init: [FAILED] Failed to start rpcbind... [FAILED] Failed to start LSB: NFS client services. See 'systemctl status nfs.service' for details. and from systemctl: # systemctl status rpcbind rpcbind.service - RPC Bind Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; enabled) Active: active (running) since Tue 2014-04-22 22:49:48 EDT; 1min 0s ago Docs: man:rpcbind(8) Main PID: 1103 (rpcbind) CGroup: /system.slice/rpcbind.service ââ1103 /sbin/rpcbind -w -f hs80e rpcbind[1103]: owner=superuser hs80e rpcbind[1103]: Suppression RPC_UNSET(map_unset) hs80e rpcbind[1103]: rbl->rpcb_map.r_owner=superuser hs80e rpcbind[1103]: owner=superuser hs80e rpcbind[1103]: Suppression RPC_UNSET(map_unset) hs80e rpcbind[1103]: rbl->rpcb_map.r_owner=superuser hs80e rpcbind[1103]: owner=superuser hs80e rpcbind[1103]: Suppression RPC_UNSET(map_unset) hs80e rpcbind[1103]: rbl->rpcb_map.r_owner=superuser hs80e rpcbind[1103]: owner=superuser # systemctl status nfs nfs.service - LSB: NFS client services Loaded: loaded (/etc/init.d/nfs) Drop-In: /run/systemd/generator/nfs.service.d ââ50-insserv.conf-$remote_fs.conf Active: failed (Result: exit-code) since Tue 2014-04-22 22:49:45 EDT; 1min 20s ago Process: 1063 ExecStart=/etc/init.d/nfs start (code=exited, status=3) hs80e nfs[1063]: Starting NFS client services:portmap/rpcbind is not running hs80e nfs[1063]: ..missing hs80e systemd[1]: nfs.service: control process exited, code=exited status=3 hs80e systemd[1]: Failed to start LSB: NFS client services. hs80e systemd[1]: Unit nfs.service entered failed state. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Anton Aylward
-
Bernhard Voelker
-
Carlos E. R.
-
David Haller
-
Felix Miata
-
Joachim Schrod
-
John Andersen
-
Patrick Shanahan