RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1476343 - autofs breaks stunnel mounted NFSv4 shares
Summary: autofs breaks stunnel mounted NFSv4 shares
Keywords:
Status: CLOSED DUPLICATE of bug 1463004
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: autofs
Version: 6.9
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Ian Kent
QA Contact: Filesystem QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-28 16:40 UTC by Scott Greenberg
Modified: 2021-09-09 12:28 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-02 00:03:01 UTC
Target Upstream Version:
Embargoed:
sgreenbe: needinfo-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
CentOS 0013575 0 None None None 2017-07-28 16:52:06 UTC

Description Scott Greenberg 2017-07-28 16:40:55 UTC
Description of problem:

The autofs package that was released with RHEL 6.8 (autofs-5.0.5-122) worked properly over an stunnel connection.

The release shipped with RHEL 6.9 (5.0.5-132) prevents any connection from happening to the local stunnel process and breaks mounts to remote systems over stunnel connections.

Version-Release number of selected component (if applicable):

5.0.5-132

How reproducible:

There is a reliable reproducer.

Steps to Reproduce:

1) Set up a server/client stunnel connection targeted to port 2049
2) Set up an NFSv4 mount on the NFS server that binds to stunnel
3) Set up an NFSv4 automount on the NFS client that binds to stunnel
4) Attempt to mount the autofs location via navigating to the directory

A sample working environment with a failing test can be generated by doing the following:

1) Set up RVM (https://rvm.io/) and install Ruby version 2.1.9 and bundler
2) Run `git clone https://github.com/simp/pupmod-simp-simp_nfs
3) Run 'cd pupmod-simp-simp_nfs'
4) Run 'bundle update'
5) Ensure that VirtualBox is installed and properly functioning and has space to spawn around 4 systems
6) Run 'BEAKER_destroy=onpass bundle exec rake beaker:suites[stunnel]'
7) On failure, navigate to './vagrant/beaker_vagrant_files/default.yml'
8) Run 'vagrant ssh client6 -- -l root' in two different windows
9) Run 'service autofs stop'
10) Run 'automount -fvd'
11) Run 'cd /home/test.user' in the other window and watch the output of 'automount'

Actual results:

The following error message is output by 'automount -fvd':

[root@client6 etc]# automount -f -vd
Starting automounter version 5.0.5-132.el6, master map auto.master
using kernel protocol version 5.02
lookup_nss_read_master: reading master files auto.master
do_init: parse(sun): init gathered global options: (null)
lookup_read_master: lookup(file): read entry /home
master_do_mount: mounting /home
automount_path_to_fifo: fifo name /var/run/autofs.fifo-home
lookup_nss_read_map: reading map file /etc/autofs/home.map
do_init: parse(sun): init gathered global options: (null)
mounted indirect on /home with timeout 300, freq 75 seconds
st_ready: st_ready(): state = 0 path /home
handle_packet: type = 3
handle_packet_missing_indirect: token 194, name test.user, request pid 24290
attempting to mount entry /home/test.user
lookup_mount: lookup(file): looking up test.user
lookup_mount: lookup(file): test.user -> -fstype=nfs4,port=2049,sec=sys 127.0.0.1:/home/&
parse_mount: parse(sun): expanded entry: -fstype=nfs4,port=2049,sec=sys 127.0.0.1:/home/test.user
parse_mount: parse(sun): gathered options: fstype=nfs4,port=2049,sec=sys
parse_mount: parse(sun): dequote("127.0.0.1:/home/test.user") -> 127.0.0.1:/home/test.user
parse_mount: parse(sun): core of entry: options=fstype=nfs4,port=2049,sec=sys, loc=127.0.0.1:/home/test.user
sun_mount: parse(sun): mounting root /home, mountpoint test.user, what 127.0.0.1:/home/test.user, fstype nfs4, options port=2049,sec=sys
mount_mount: mount(nfs): root=/home name=test.user what=127.0.0.1:/home/test.user, fstype=nfs4, options=port=2049,sec=sys
mount_mount: mount(nfs): nfs options="port=2049,sec=sys", nobind=0, nosymlink=0, ro=0
mount_mount: mount(nfs): calling mkdir_path /home/test.user
mount(nfs): nfs: mount failure 127.0.0.1:/home/test.user on /home/test.user
dev_ioctl_send_fail: token = 194
failed to mount /home/test.user
handle_packet: type = 3
handle_packet_missing_indirect: token 195, name test.user, request pid 24290
dev_ioctl_send_fail: token = 195
statemachine:1472: got unexpected signal 28!

Expected results:

Normal expected behavior without errors. 

Additional info:

This has been filed as a CentOS bug here: 

https://bugs.centos.org/view.php?id=13575

The customer who filed that bug has indicated that the bug is reproducible in RHEL as well.

Comment 3 Ian Kent 2017-07-29 00:43:28 UTC
(In reply to Scott Greenberg from comment #0)
> Description of problem:
> 
> The autofs package that was released with RHEL 6.8 (autofs-5.0.5-122) worked
> properly over an stunnel connection.
> 
> The release shipped with RHEL 6.9 (5.0.5-132) prevents any connection from
> happening to the local stunnel process and breaks mounts to remote systems
> over stunnel connections.
> 

This sounds a lot like bug 1463004, yes it was my mistake, very sorry
I missed it.

The test package referred to in bug 1463004 is still present on
people.redhat.com. Could you please check if it resolves the problem.

That's the package at:
http://people.redhat.com/~ikent/autofs-5.0.5-132.bz1463004.2.el6_9/

Comment 4 Ian Kent 2017-07-29 01:10:12 UTC
(In reply to Scott Greenberg from comment #0)
> parse_mount: parse(sun): core of entry:
> options=fstype=nfs4,port=2049,sec=sys, loc=127.0.0.1:/home/test.user
> sun_mount: parse(sun): mounting root /home, mountpoint test.user, what
> 127.0.0.1:/home/test.user, fstype nfs4, options port=2049,sec=sys
> mount_mount: mount(nfs): root=/home name=test.user
> what=127.0.0.1:/home/test.user, fstype=nfs4, options=port=2049,sec=sys
> mount_mount: mount(nfs): nfs options="port=2049,sec=sys", nobind=0,
> nosymlink=0, ro=0
> mount_mount: mount(nfs): calling mkdir_path /home/test.user
> mount(nfs): nfs: mount failure 127.0.0.1:/home/test.user on /home/test.user
> dev_ioctl_send_fail: token = 194

The failure case does look a bit different to bug 1463004.

Maybe there's something more I've missed, interested to see a
debug log from the test package if it still fails.

> failed to mount /home/test.user
> handle_packet: type = 3
> handle_packet_missing_indirect: token 195, name test.user, request pid 24290
> dev_ioctl_send_fail: token = 195
> statemachine:1472: got unexpected signal 28!

That's odd, an ENOSPC error, wonder where that came from.

Ian


Note You need to log in before you can comment on or make changes to this bug.