This is a tracking bug for Change: Add amd map parser to autofs For more details, see: http://fedoraproject.org//wiki/Changes/Add_amd_map_parser_to_autofs The am-utils package provides automount services for automount maps that use an amd format. However, the am-utils project has not been actively maintained for quite a while now.
Great, thanks. Beta is still several days away yet, so update won't be done just yet.
Rawhide has been updated with autofs-5.0.1-beta1. See https://koji.fedoraproject.org/koji/buildinfo?buildID=508597 for build details.
(In reply to Ian Kent from comment #2) > Rawhide has been updated with autofs-5.0.1-beta1. > See https://koji.fedoraproject.org/koji/buildinfo?buildID=508597 > for build details. Excuse me that's autofs-5.1.0-beta1, sorry.
More information from README.amd-maps: amd map parser ============== The ability to parse amd format maps has been added to autofs. How to use amd maps in autofs ----------------------------- To add amd map parsing to autofs new "format" module has been added. To use this new map format module the existing master map syntax is used as described below. The master map entry syntax is: mount-point [map-type[,format]:]map [options] For amd format maps this becomes: /amd/mp file,amd:amd.mp which will use file as the map source and the amd format parser for the map. But see the section below on configuration below for how to eliminate the need to specify "map-type,format" in the master map. Configuration sub-system changes -------------------------------- The configuration sub-system has changed to accommodate the amd parser. See autofs.conf(5) for more information on format changes. The configuration is now split into system initialization only configuration and the daemon configuration. Previously everything was located in the system initialization configuration file, but now the configuration is located in autofs.conf in the directory the distribution uses for the autofs configuration. There is information about what amd configuration entries can be used in comments of the installed configuration so that's worth a look. All that's needed to add an existing amd configuration to autofs is to add it below the autofs configuration. Apart from changing the amd "[ global ]" section name to "[ amd ]" nothing else should need to be changed. However, quite a few amd configuration options don't have meaning within autofs. When these options are seen it should be logged. Be aware that, if the an old configuration exists and the configuration hasn't been updated after the installation, changes to the the old configuration will override changes to the new configuration because backward compatibility takes priority over the new implementation. The amd per-map sections have two functions, to allow per-mount configuration, as it does in amd, and to allow master map entries to avoid the need to specify the "type,format" part of the master map entry so they can use the nsswitch map source functionality in the same way autofs master map entries do. If a section for an amd mount is added below the global amd section using the mount point path (as is done in amd.conf) then autofs will know the map format is amd (it doesn't matter if there are no other configuration options in the mount point section). Since the map must be given in the master map entry the map_name option is not mandatory as it is in amd and will no be used. If a mount point is present in the master map and the source of the map is nis then it should be sufficient to use (for example): /amd/mp amd.mp in the master map and automount: nis in /etc/nsswitch.conf or [ amd ] map_type = nis in the configuration along with [ /amd/mp ] or [ /amd/mp ] map_type = nis amd map options that can be used -------------------------------- In an attempt to describe the usable amd map options, many of the amd map options have been added to autofs(5). Not all the amd functionality has been implemented. The autofs(5) man page usually mentions if something hasn't been implemented so that's worth checking. What hasn't been implemented ---------------------------- The configuration options fully_qualified_hosts, unmount_on_exit and browsable_dirs (and a couple of others) aren't implemented. Map types (sources) ndbm, passwd are not implemented. The map source "sss" can't be used for amd format maps. Map caching options aren't used, the existing autofs map caching is always used for available map sources. The regex map key matching feature is not implemented. Mount types lustre, nfsx, jfs, program and direct haven't been implemented and other mount types that aren't implemented in amd are also not available. How to find out more -------------------- Have a look at the man pages autofs.conf(5), autofs(5) and to a lesser extent auto.master(5). These may help. But the best way to get more information is to ask on the autofs mailing list as described in the README file.
This message is a reminder that Fedora 21 Accepted Changes Freeze Deadline is on 2014-07-08 [1]. At this point, all accepted Changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be so enabled at Change Freeze. This bug should be set to the MODIFIED state to indicate that it achieved completeness. Status will be provided to FESCo right after the deadline. If, for any reasons, your Change is not in required state, let me know and we will try to find solution. For Changes you decide to cancel/move to the next release, please use the NEW status and set needinfo on me and it will be acted upon. In case of any questions, don't hesitate to ask Wrangler (jreznik). Thank you. [1] https://fedoraproject.org/wiki/Releases/21/Schedule
(In reply to Jaroslav Reznik from comment #5) > This message is a reminder that Fedora 21 Accepted Changes Freeze Deadline > is on 2014-07-08 [1]. > > At this point, all accepted Changes should be substantially complete, and > testable. Additionally, if a change is to be enabled by default, it must be > so enabled at Change Freeze. > > This bug should be set to the MODIFIED state to indicate that it achieved > completeness. Status will be provided to FESCo right after the deadline. If, > for any reasons, your Change is not in required state, let me know and we > will try to find solution. For Changes you decide to cancel/move to the next > release, please use the NEW status and set needinfo on me and it will be > acted upon. The change is done but I'm working on some additional fixes identified by Coverity. I'd like to try and include as many of those as I can before the freeze. In any case I'll include what I can before the freeze and move this bug to MODIFIED in time. Ian
This message is a reminder that Fedora 21 Change Checkpoint: 100% Code Complete Deadline (Former Accepted Changes 100% Complete) is on 2014-10-14 [1]. All Accepted Changes has to be code complete and ready to be validated in the Beta release (optionally by Fedora QA). Required bug state at this point is ON_QA. As for several System Wide Changes, Beta Change Deadline is a point of contingency plan. All incompleted Changes will be reported to FESCo on 2014-10-15 meeting. In case of any questions, don't hesitate to ask Wrangler (jreznik). [1] https://fedoraproject.org/wiki/Releases/21/Schedule
(In reply to Jaroslav Reznik from comment #7) > This message is a reminder that Fedora 21 Change Checkpoint: 100% Code > Complete Deadline (Former Accepted Changes 100% Complete) is on 2014-10-14 > [1]. > > All Accepted Changes has to be code complete and ready to be validated in > the Beta release (optionally by Fedora QA). Required bug state at this point > is ON_QA. Sorry, I'm not clear on this. What is it I need to do, other than set the bug to MODIFIED for QA to pick it up and set it to ON_QA?
(In reply to Ian Kent from comment #8) > (In reply to Jaroslav Reznik from comment #7) > > This message is a reminder that Fedora 21 Change Checkpoint: 100% Code > > Complete Deadline (Former Accepted Changes 100% Complete) is on 2014-10-14 > > [1]. > > > > All Accepted Changes has to be code complete and ready to be validated in > > the Beta release (optionally by Fedora QA). Required bug state at this point > > is ON_QA. > > Sorry, I'm not clear on this. > What is it I need to do, other than set the bug to MODIFIED for > QA to pick it up and set it to ON_QA? Use ON_QA to say it's done and ready for QA. Unfortunately, we had to map change states somehow to the few states available in Bugzilla. ON_QA in this case means - change 100% code completed.
(In reply to Jaroslav Reznik from comment #9) > (In reply to Ian Kent from comment #8) > > (In reply to Jaroslav Reznik from comment #7) > > > This message is a reminder that Fedora 21 Change Checkpoint: 100% Code > > > Complete Deadline (Former Accepted Changes 100% Complete) is on 2014-10-14 > > > [1]. > > > > > > All Accepted Changes has to be code complete and ready to be validated in > > > the Beta release (optionally by Fedora QA). Required bug state at this point > > > is ON_QA. > > > > Sorry, I'm not clear on this. > > What is it I need to do, other than set the bug to MODIFIED for > > QA to pick it up and set it to ON_QA? > > Use ON_QA to say it's done and ready for QA. Unfortunately, we had to map > change states somehow to the few states available in Bugzilla. > > ON_QA in this case means - change 100% code completed. Thanks for the information. I'm going to set ON_QA for this now. I have a couple of bug fix patches but, due to the code freeze, I'm planning on adding them as day-0 changes. If that's not OK can you direct me to the page which describes the process of requesting a package update during code freeze, I can't find it. Ian
I've added a note in the Release Notes for this change, please take a look. https://git.fedorahosted.org/cgit/docs/release-notes.git/commit/?id=3a0ff39a235dbf12fd09f16a60c33dbbabc83538
(In reply to Pete Travis from comment #11) > I've added a note in the Release Notes for this change, please take a look. > > https://git.fedorahosted.org/cgit/docs/release-notes.git/commit/ > ?id=3a0ff39a235dbf12fd09f16a60c33dbbabc83538 That looks great. Except for s/rpstream/upstream/ typo, ;)
Thanks Ian - I fixed that in the next commit :)
(In reply to Ian Kent from comment #10) > > I'm going to set ON_QA for this now. > I have a couple of bug fix patches but, due to the code freeze, I'm > planning on adding them as day-0 changes. > On second thoughts, looking at the bug fix patches there are a couple of memory leak fixes and a couple of amd-parser fixes that should go into the beta. I'll queue them up for push following the freeze. Ian