nfs-utils, e_maptype

nfs-utils, e_maptype

[J. Bruce Fields]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs-utils, e_maptype

[Olaf Kirch]

On Wednesday 07 March 2007 03:21, J. Bruce Fields wrote:
> 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
-- 
Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs-utils, e_maptype

[J. Bruce Fields]

On Wed, Mar 07, 2007 at 09:23:45PM +0100, Olaf Kirch wrote:
> On Wednesday 07 March 2007 03:21, J. Bruce Fields wrote:
> > 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs-utils, e_maptype

[Olaf Kirch]

On Wednesday 07 March 2007 22:28, J. Bruce Fields wrote:
> 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
-- 
Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs-utils, e_maptype

[Talpey, Thomas]

At 03:49 AM 3/8/2007, Olaf Kirch wrote:
>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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs-utils, e_maptype

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 951 bytes --]

On Thu, 8 Mar 2007, Talpey, Thomas wrote:

> At 03:49 AM 3/8/2007, Olaf Kirch wrote:
> >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.

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

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs-utils, e_maptype

[Talpey, Thomas]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs-utils, e_maptype

[Neil Brown]

On Tuesday March 6, bfields@fieldses.org 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

[PATCH] Remove "maptype" support

[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.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---

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(-)

diff --git a/support/export/nfsctl.c b/support/export/nfsctl.c
index b74334c..32d92bd 100644
--- a/support/export/nfsctl.c
+++ b/support/export/nfsctl.c
@@ -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);
diff --git a/support/include/nfslib.h b/support/include/nfslib.h
index 1372635..d4f4150 100644
--- a/support/include/nfslib.h
+++ b/support/include/nfslib.h
@@ -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;
diff --git a/support/nfs/exports.c b/support/nfs/exports.c
index 9638015..0baa5d0 100644
--- a/support/nfs/exports.c
+++ b/support/nfs/exports.c
@@ -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");
diff --git a/utils/exportfs/exportfs.c b/utils/exportfs/exportfs.c
index 22e13a3..1eca567 100644
--- a/utils/exportfs/exportfs.c
+++ b/utils/exportfs/exportfs.c
@@ -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)
diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
index 4693216..6cf24ce 100644
--- a/utils/mountd/cache.c
+++ b/utils/mountd/cache.c
@@ -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;
-- 
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] Remove "maptype" support

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 640 bytes --]

On Tue, 13 Mar 2007, J. Bruce Fields wrote:

> 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

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs