nfs-utils, e_maptype · kernelthread

J. Bruce Fields

author

2007-03-07 02:20 UTC #0 lore raw

Anybody know what the e_maptype export field is for? It seems to be unused.

--b.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Olaf Kirch

2007-03-07 20:24 UTC #1 lore raw

Quoted 2 lines · J. Bruce Fields

Anybody know what the e_maptype export field is for? It seems to be unused.

IINM it goes back to the unfsd days. You could do different types of uid mapping there - 1:1 mapping, using NIS, or using some funky contraption called rpc.ugidd. Yes, we had uid mapping before NFSv4, and no, it wasnt pretty :-)

Olaf

Signature · 11 lines

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

J. Bruce Fields

author

2007-03-07 21:28 UTC #2 lore raw

Quoted 7 lines · Olaf Kirch

Quoted 2 lines · J. Bruce Fields
Anybody know what the e_maptype export field is for? It seems to be unused.
IINM it goes back to the unfsd days. You could do different types of uid mapping there - 1:1 mapping, using NIS, or using some funky contraption called rpc.ugidd. Yes, we had uid mapping before NFSv4, and no, it wasnt pretty :-)

Some things are just timeless.

So does that someone somewhere could theoretically be using this code right now? On a quick glance I'd convinced myself it was totally dead, but I wasn't thinking about unfsd. I have no clue how it interacts with anything else in nfs-utils.

--b.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Olaf Kirch

2007-03-08 08:50 UTC #3 lore raw

Quoted 4 lines · J. Bruce Fields

So does that someone somewhere could theoretically be using this code right now? On a quick glance I'd convinced myself it was totally dead, but I wasn't thinking about unfsd. I have no clue how it interacts with anything else in nfs-utils.

I think it's safe to ignore unfsd.

Olaf

Signature · 11 lines

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Talpey, Thomas

2007-03-08 12:32 UTC #4 lore raw

Quoted 1 line · Olaf Kirch

I think it's safe to ignore unfsd.

I agree, but I've been surprised to see some of the embedded (ARM) ports using it, they have .deb-style package installs and everything. Many of the users of these packages don't have a lot of NFS depth. The tiny NAS boxes in general don't even enable NFS by default, the users are on their own and unfsd means they don't have to muck with the embedded kernel.

That said, I don't think these users even know about userid mapping types. Also most of the boxes are now doing what they call knfsd. Just a data point that unfsd isn't totally dead.

Tom.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Peter Åstrand

2007-03-08 13:28 UTC #5 lore raw

Quoted 9 lines · Thomas

Quoted 1 line · Olaf Kirch
I think it's safe to ignore unfsd.
I agree, but I've been surprised to see some of the embedded (ARM) ports using it, they have .deb-style package installs and everything. Many of the users of these packages don't have a lot of NFS depth. The tiny NAS boxes in general don't even enable NFS by default, the users are on their own and unfsd means they don't have to muck with the embedded kernel.

Quoted 3 lines

That said, I don't think these users even know about userid mapping types. Also most of the boxes are now doing what they call knfsd. Just a data point that unfsd isn't totally dead.

Users of the "original" unfsd could then switch to unfs3, which doesn't depend on e_maptype.

Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.se
Teknikringen 3
583 30 Linköping Phone: +46-13-21 46 00

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Talpey, Thomas

2007-03-08 13:39 UTC #6 lore raw

Quoted 3 lines · At 08:28 AM 3/8/2007, Peter =C3=85strand wrote:

Users of the "original" unfsd could then switch to unfs3, which doesn't =
depend on e_maptype. =

Good point - and unfs3 is there in the main ones already.

Okay, I agree let's ignore unfsd altogether.

Tom.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Neil Brown

2007-03-13 05:25 UTC #7 lore raw

In reply to J. Bruce Fields

Quoted 3 lines · On Tuesday March 6, [email protected] wrote:

Anybody know what the e_maptype export field is for? It seems to be unused.

So, am I expecting a patch for 1.0.10 to remove e_maptype? That would be nice .... I'm keen on getting rid of old cruft with this release. rpc.lockd is already gone.

NeilBrown

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

J. Bruce Fields

author

2007-03-13 17:05 UTC #8 lore raw

PATCH 1/1 Remove "maptype" support

It appears that this is used only by unfsd, and is obscure enough that we should be able to just rip it out with no special precautions.

Signed-off-by "J. Bruce Fields" <[email protected]>

---

Also available from git://linux-nfs.org/~bfields/nfs-utils.git.

 support/export/nfsctl.c   |    6 ------
 support/include/nfslib.h  |    7 -------
 support/nfs/exports.c     |   37 -------------------------------------
 utils/exportfs/exportfs.c |    4 ----
 utils/mountd/cache.c      |    6 ------
 5 files changed, 0 insertions(+), 60 deletions(-)

support/export/nfsctl.c +0 -6

index b74334c..32d92bd 100644
@@ -92,12 +92,6 @@ expsetup(struct nfsctl_export *exparg, nfs_export *exp, int unexport)
 	if (stat(exp->m_export.m_path, &stb) < 0)
 		return 0;
 
-	if (exp->m_export.e_maptype != CLE_MAP_IDENT) {
-		xlog(L_ERROR, "%s: unsupported mapping; kernel supports only 'identity' (default)",
-		     exp->m_export.m_path);
-		errno = EINVAL;
-		return 0;
-	}
 	memset(exparg, 0, sizeof(*exparg));
 	strncpy(exparg->ex_path, exp->m_export.m_path,
 		sizeof (exparg->ex_path) - 1);

support/include/nfslib.h +0 -7

index 1372635..d4f4150 100644
@@ -51,12 +51,6 @@
 #define	_PATH_PROC_EXPORTS_ALT	"/proc/fs/nfsd/exports"
 #endif
 
-enum cle_maptypes {
-	CLE_MAP_IDENT = 0,
-	CLE_MAP_FILE,
-	CLE_MAP_UGIDD,
-};
-
 /*
  * Data related to a single exports entry as returned by getexportent.
  * FIXME: export options should probably be parsed at a later time to

@@ -71,7 +65,6 @@ struct exportent {
 	   use it for anything else. */
 	char		m_path[NFS_MAXPATHLEN+1];
 	int		e_flags;
-	int		e_maptype;
 	int		e_anonuid;
 	int		e_anongid;
 	int *		e_squids;

support/nfs/exports.c +0 ~~-37~~

index 9638015..0baa5d0 100644
@@ -48,7 +48,6 @@ static int	getpath(char *path, int len);
 static int	parseopts(char *cp, struct exportent *ep, int warn, int *had_subtree_opt_ptr);
 static int	parsesquash(char *list, int **idp, int *lenp, char **ep);
 static int	parsenum(char **cpp);
-static int	parsemaptype(char *type);
 static void	freesquash(void);
 static void	syntaxerr(char *msg);

@@ -94,7 +93,6 @@ getexportent(int fromkernel, int fromexports)
 			def_ee.e_flags &= ~NFSEXP_ASYNC;
 			def_ee.e_flags &= ~NFSEXP_GATHERED_WRITES;
 		}
-		def_ee.e_maptype = CLE_MAP_IDENT;
 		def_ee.e_anonuid = 65534;
 		def_ee.e_anongid = 65534;
 		def_ee.e_squids = NULL;

@@ -245,21 +243,6 @@ putexportent(struct exportent *ep)
 		xlog(L_ERROR, "unknown fsloc method for %s:%s",
 		     ep->e_hostname, ep->e_path);
 	}
-	fprintf(fp, "mapping=");
-	switch (ep->e_maptype) {
-	case CLE_MAP_IDENT:
-		fprintf(fp, "identity,");
-		break;
-	case CLE_MAP_UGIDD:
-		fprintf(fp, "ugidd,");
-		break;
-	case CLE_MAP_FILE:
-		fprintf(fp, "file,");
-		break;
-	default:
-		xlog(L_ERROR, "unknown mapping type for %s:%s",
-					ep->e_hostname, ep->e_path);
-	}
 	if ((id = ep->e_squids) != NULL) {
 		fprintf(fp, "squash_uids=");
 		for (i = 0; i < ep->e_nsquids; i += 2)

@@ -317,7 +300,6 @@ mkexportent(char *hname, char *path, char *options)
 	static struct exportent	ee;
 
 	ee.e_flags = EXPORT_DEFAULT_FLAGS;
-	ee.e_maptype = CLE_MAP_IDENT;
 	ee.e_anonuid = 65534;
 	ee.e_anongid = 65534;
 	ee.e_squids = NULL;

@@ -447,12 +429,6 @@ parseopts(char *cp, struct exportent *ep, int warn, int *had_subtree_opt_ptr)
 			ep->e_flags &= ~NFSEXP_NOACL;
 		else if (strcmp(opt, "no_acl") == 0)
 			ep->e_flags |= NFSEXP_NOACL;
-		else if (strncmp(opt, "mapping=", 8) == 0)
-			ep->e_maptype = parsemaptype(opt+8);
-		else if (strcmp(opt, "map_identity") == 0)	/* old style */
-			ep->e_maptype = CLE_MAP_IDENT;
-		else if (strcmp(opt, "map_daemon") == 0)	/* old style */
-			ep->e_maptype = CLE_MAP_UGIDD;
 		else if (strncmp(opt, "anonuid=", 8) == 0) {
 			char *oe;
 			ep->e_anonuid = strtol(opt+8, &oe, 10);

@@ -625,19 +601,6 @@ parsenum(char **cpp)
 }
 
 static int
-parsemaptype(char *type)
-{
-	if (!strcmp(type, "identity"))
-		return CLE_MAP_IDENT;
-	if (!strcmp(type, "ugidd"))
-		return CLE_MAP_UGIDD;
-	if (!strcmp(type, "file"))
-		return CLE_MAP_FILE;
-	syntaxerr("invalid map type");
-	return CLE_MAP_IDENT;	/* default */
-}
-
-static int
 getpath(char *path, int len)
 {
 	xskip(efp, " \t\n");

utils/exportfs/exportfs.c +0 -4

index 22e13a3..1eca567 100644
@@ -410,10 +410,6 @@ dump(int verbose)
 				c = dumpopt(c, "mountpoint%s%s", 
 					    ep->e_mountpoint[0]?"=":"", 
 					    ep->e_mountpoint);
-			if (ep->e_maptype == CLE_MAP_UGIDD)
-				c = dumpopt(c, "mapping=ugidd");
-			else if (ep->e_maptype == CLE_MAP_FILE)
-				c = dumpopt(c, "mapping=file");
 			if (ep->e_anonuid != 65534)
 				c = dumpopt(c, "anonuid=%d", ep->e_anonuid);
 			if (ep->e_anongid != 65534)

utils/mountd/cache.c +0 -6

index 4693216..6cf24ce 100644
@@ -612,12 +612,6 @@ int cache_export(nfs_export *exp)
 	int err;
 	FILE *f;
 
-	if (exp->m_export.e_maptype != CLE_MAP_IDENT) {
-		xlog(L_ERROR, "%s: unsupported mapping; kernel supports only 'identity' (default)",
-		    exp->m_export.m_path);
-		return -1;
-	}
-
 	f = fopen("/proc/net/rpc/auth.unix.ip/channel", "w");
 	if (!f)
 		return -1;

Signature · 11 lines

1.5.0.gb75812-dirty


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Peter Åstrand

2007-03-13 17:24 UTC #9 lore raw

Re: [PATCH] Remove "maptype" support

Quoted 2 lines · J. Bruce Fields

It appears that this is used only by unfsd, and is obscure enough that we should be able to just rip it out with no special precautions.

Btw, I checked the source of nfs-server-2.2beta47, which is available from
http://sourceforge.net/project/showfiles.php?group_id=5768, and I can't find any references to "maptype" in this source either.

As far as I know, nfs-server-2.2beta47 is the latest version of the old unfsd code.

Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.se
Teknikringen 3
583 30 Linköping Phone: +46-13-21 46 00

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs