Now that the use of numeric uids/gids is officially sanctioned in
RFC3530bis, it is time to change the default here to 'enabled'.
By doing so, we ensure that NFSv4 copies the behaviour of NFSv3 when we're
using the default AUTH_SYS authentication (i.e. when the client uses the
numeric uids/gids as authentication tokens), so that when new files are
created, they will appear to have the correct user/group.
It also fixes a number of backward compatibility issues when migrating
from NFSv3 to NFSv4 on a platform where the server uses different uid/gid
mappings than the client.
Note also that this setting has been successfully tested against servers
that do not support numeric uids/gids at several Connectathon/Bakeathon
events at this point, and the fall back to using string names/groups has
been shown to work well in all those test cases.
Signed-off-by: Trond Myklebust <[email protected]>
---
Documentation/kernel-parameters.txt | 17 +++++++++++------
fs/nfs/client.c | 2 +-
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 81c287f..dfd21cf 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1630,12 +1630,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
The default is to return 64-bit inode numbers.
nfs.nfs4_disable_idmapping=
- [NFSv4] When set, this option disables the NFSv4
- idmapper on the client, but only if the mount
- is using the 'sec=sys' security flavour. This may
- make migration from legacy NFSv2/v3 systems easier
- provided that the server has the appropriate support.
- The default is to always enable NFSv4 idmapping.
+ [NFSv4] When set to the default of '1', this option
+ ensures that both the RPC level authentication
+ scheme and the NFS level operations agree to use
+ numeric uids/gids if the mount is using the
+ 'sec=sys' security flavour. In effect it is
+ disabling idmapping, which can make migration from
+ legacy NFSv2/v3 systems to NFSv4 easier.
+ Servers that do not support this mode of operation
+ will be autodetected by the client, and it will fall
+ back to using the idmapper.
+ To turn off this behaviour, set the value to '0'.
nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take
when a NMI is triggered.
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 41bd67f..277dfaf 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -84,7 +84,7 @@ retry:
/*
* Turn off NFSv4 uid/gid mapping when using AUTH_SYS
*/
-static int nfs4_disable_idmapping = 0;
+static int nfs4_disable_idmapping = 1;
/*
* RPC cruft for NFS
--
1.7.7.5
On Thu, Mar 22, 2012 at 09:01:12PM +0000, Myklebust, Trond wrote:
> On Thu, 2012-03-22 at 16:53 -0400, Trond Myklebust wrote:
> > Does the idmapper do the right thing for numeric ids these days? If the
> > older clients are running a newer idmapper that can deal with numeric
> > ids, then even the legacy clients should be able to work cleanly.
>
> If this isn't the case, then the older clients are broken anyway. The
> server has always had the option of returning numeric ids if it has no
> mapping from a uid/gid into an owner/group string.
Hm, yes, but I was worried that the id<->name mapping might just be
different on the two sides--but if that's so, and they were using
auth_sys, then they likely already had problems.
So, maybe we could default this to on.
If that's the case then I'd rather not bother making this per export:
just an option to get the server back to its previous behavior would
seem enough.
--b.
> IOW: the only difference between older and newer clients should really
> be that the newer ones handle numeric strings more efficiently without
> requiring an upcall, and that the newer clients will also try to _send_
> numeric ids in SETATTR calls.
>
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> [email protected]
> http://www.netapp.com
>
On Thu, Mar 22, 2012 at 04:47:05PM -0400, bfields wrote:
> By the way, I finally got around to looking at the server side.
>
> We don't have any way to negotiate with the client--we don't get an
> error back if the name we return in a getattr reply isn't one the client
> likes--so I don't think I can default the new behavior to "on" without
> breaking existing setups.
But we should still be able to make this effectively the default on new
server installations: maybe:
- Have the new module parameter be set based on a new
"ServerNumericMapping" variable in idmapd.conf defaults to
off.
- Set it to "on" in the example idmapd.conf we distribute
upstream, and encourage distributions to do the same in the
idmapd.conf they install by default.
--b.
>
> Other than that I think I'll just copy the client, module parameter and
> all. That allows us to do the numeric case in-kernel and avoid
> polluting our mapping cache with lots of "obvious" 123<->"123" mappings.
T24gVGh1LCAyMDEyLTAzLTIyIGF0IDE2OjQ3IC0wNDAwLCBKLiBCcnVjZSBGaWVsZHMgd3JvdGU6
DQo+IEJ5IHRoZSB3YXksIEkgZmluYWxseSBnb3QgYXJvdW5kIHRvIGxvb2tpbmcgYXQgdGhlIHNl
cnZlciBzaWRlLg0KPiANCj4gV2UgZG9uJ3QgaGF2ZSBhbnkgd2F5IHRvIG5lZ290aWF0ZSB3aXRo
IHRoZSBjbGllbnQtLXdlIGRvbid0IGdldCBhbg0KPiBlcnJvciBiYWNrIGlmIHRoZSBuYW1lIHdl
IHJldHVybiBpbiBhIGdldGF0dHIgcmVwbHkgaXNuJ3Qgb25lIHRoZSBjbGllbnQNCj4gbGlrZXMt
LXNvIEkgZG9uJ3QgdGhpbmsgSSBjYW4gZGVmYXVsdCB0aGUgbmV3IGJlaGF2aW9yIHRvICJvbiIg
d2l0aG91dA0KPiBicmVha2luZyBleGlzdGluZyBzZXR1cHMuDQo+IA0KPiBPdGhlciB0aGFuIHRo
YXQgSSB0aGluayBJJ2xsIGp1c3QgY29weSB0aGUgY2xpZW50LCBtb2R1bGUgcGFyYW1ldGVyIGFu
ZA0KPiBhbGwuICBUaGF0IGFsbG93cyB1cyB0byBkbyB0aGUgbnVtZXJpYyBjYXNlIGluLWtlcm5l
bCBhbmQgYXZvaWQNCj4gcG9sbHV0aW5nIG91ciBtYXBwaW5nIGNhY2hlIHdpdGggbG90cyBvZiAi
b2J2aW91cyIgMTIzPC0+IjEyMyIgbWFwcGluZ3MuDQo+IA0KPiAoT0ssIG1heWJlIEkgc2hvdWxk
bid0IGNvcHkgdGhlIHNhbWUgcGFyYW1ldGVyIG5hbWUsIHRob3VnaC0tZXZlbiBpZiBpdA0KPiB3
b3JrcyBpdCBtaWdodCBiZSBjb25mdXNpbmcuKQ0KDQpEb2VzIHRoZSBpZG1hcHBlciBkbyB0aGUg
cmlnaHQgdGhpbmcgZm9yIG51bWVyaWMgaWRzIHRoZXNlIGRheXM/IElmIHRoZQ0Kb2xkZXIgY2xp
ZW50cyBhcmUgcnVubmluZyBhIG5ld2VyIGlkbWFwcGVyIHRoYXQgY2FuIGRlYWwgd2l0aCBudW1l
cmljDQppZHMsIHRoZW4gZXZlbiB0aGUgbGVnYWN5IGNsaWVudHMgc2hvdWxkIGJlIGFibGUgdG8g
d29yayBjbGVhbmx5Lg0KDQpPdGhlcndpc2UsIHRoZXJlIGlzIGFsc28gdGhlIGFsdGVybmF0aXZl
IG9mIG1ha2luZyB0aGUgd2hvbGUgdGhpbmcgYQ0KcGVyLWNsaWVudCBleHBvcnQgb3B0aW9uLi4u
DQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXINCg0K
TmV0QXBwDQpUcm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbQ0Kd3d3Lm5ldGFwcC5jb20NCg0K
On 03/22/2012 03:11 PM, Boaz Harrosh wrote:
> I fail to see an opposite scenario where
> the brokenness was good, and now it will be bad.
>
I might be wrong in this regard, Though. I'm not totally
on top of all the possible cases.
Is there a way to Bata test this on large setups? What
if you make the default Kconfig(urable) so DISTROs can
compile with a new default and have a large scale testing
like in a rawhide version.
Thanks
Boaz
By the way, I finally got around to looking at the server side.
We don't have any way to negotiate with the client--we don't get an
error back if the name we return in a getattr reply isn't one the client
likes--so I don't think I can default the new behavior to "on" without
breaking existing setups.
Other than that I think I'll just copy the client, module parameter and
all. That allows us to do the numeric case in-kernel and avoid
polluting our mapping cache with lots of "obvious" 123<->"123" mappings.
(OK, maybe I shouldn't copy the same parameter name, though--even if it
works it might be confusing.)
(Untested.)
--b.
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 0d79a88..aa90574 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1686,6 +1686,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
The default is to send the implementation identification
information.
+ nfsd.nfs4_disable_idmapping=
+ [NFSv4] When set to to '1', the NFSv4 server
+ will return only numeric uids and gids to clients
+ using auth_sys, and will expect numeric uids and
+ gids from such clients. This intended to ease
+ migration from NFSv2/v3. The default is '0' for
+ backwards-compatibility reasons, but '1' is
+ recommended for any newly set up server.
objlayoutdriver.osd_login_prog=
[NFS] [OBJLAYOUT] sets the pathname to the program which
diff --git a/fs/nfsd/nfs4idmap.c b/fs/nfsd/nfs4idmap.c
index 9409627..4a1e3ce 100644
--- a/fs/nfsd/nfs4idmap.c
+++ b/fs/nfsd/nfs4idmap.c
@@ -41,6 +41,14 @@
#include "nfsd.h"
/*
+ * Turn off idmapping when using AUTH_SYS.
+ */
+static bool nfs4_disable_idmapping = false;
+module_param(nfs4_disable_idmapping, bool, 0644);
+MODULE_PARM_DESC(nfs4_disable_idmapping,
+ "Turn off server's NFSv4 idmapping when using 'sec=sys'");
+
+/*
* Cache entry
*/
@@ -561,28 +569,60 @@ idmap_id_to_name(struct svc_rqst *rqstp, int type, uid_t id, char *name)
return ret;
}
+static __be32
+numeric_name_to_id(struct svc_rqst *rqstp, int type, const char *name, u32 namelen, uid_t *id)
+{
+ int ret;
+ char buf[11];
+
+ if (namelen + 1 > sizeof(buf))
+ /* too long to represent a 32-bit id: */
+ return nfserr_badowner;
+ /* Just to make sure it's null-terminated: */
+ memcpy(buf, name, namelen);
+ buf[namelen] = '\0';
+ ret = strict_strtoul(name, 10, (unsigned long *)id);
+ return ret ? nfserr_badowner : 0;
+}
+
+static __be32
+do_name_to_id(struct svc_rqst *rqstp, int type, const char *name, u32 namelen, uid_t *id)
+{
+ if (nfs4_disable_idmapping && rqstp->rq_flavor < RPC_AUTH_GSS)
+ return numeric_name_to_id(rqstp, type, name, namelen, id);
+ return idmap_name_to_id(rqstp, type, name, namelen, id);
+}
+
+static int
+do_id_to_name(struct svc_rqst *rqstp, int type, uid_t id, char *name)
+{
+ if (nfs4_disable_idmapping && rqstp->rq_flavor < RPC_AUTH_GSS)
+ return sprintf(name, "%u", id);
+ return idmap_id_to_name(rqstp, type, id, name);
+}
+
__be32
nfsd_map_name_to_uid(struct svc_rqst *rqstp, const char *name, size_t namelen,
__u32 *id)
{
- return idmap_name_to_id(rqstp, IDMAP_TYPE_USER, name, namelen, id);
+ return do_name_to_id(rqstp, IDMAP_TYPE_USER, name, namelen, id);
}
__be32
nfsd_map_name_to_gid(struct svc_rqst *rqstp, const char *name, size_t namelen,
__u32 *id)
{
- return idmap_name_to_id(rqstp, IDMAP_TYPE_GROUP, name, namelen, id);
+ return do_name_to_id(rqstp, IDMAP_TYPE_GROUP, name, namelen, id);
}
int
nfsd_map_uid_to_name(struct svc_rqst *rqstp, __u32 id, char *name)
{
- return idmap_id_to_name(rqstp, IDMAP_TYPE_USER, id, name);
+ return do_id_to_name(rqstp, IDMAP_TYPE_USER, id, name);
}
int
nfsd_map_gid_to_name(struct svc_rqst *rqstp, __u32 id, char *name)
{
- return idmap_id_to_name(rqstp, IDMAP_TYPE_GROUP, id, name);
+ return do_id_to_name(rqstp, IDMAP_TYPE_GROUP, id, name);
}
On Thu, Mar 22, 2012 at 03:16:42PM -0700, Boaz Harrosh wrote:
> On 03/22/2012 03:11 PM, Boaz Harrosh wrote:
> > I fail to see an opposite scenario where
> > the brokenness was good, and now it will be bad.
> >
>
> I might be wrong in this regard, Though. I'm not totally
> on top of all the possible cases.
>
> Is there a way to Bata test this on large setups? What
> if you make the default Kconfig(urable) so DISTROs can
> compile with a new default and have a large scale testing
> like in a rawhide version.
That'll be easy enough to patch if it turns out to be useful.
But if we're going to default to on, then let's keep it simple for now.
And increase the chance that we get any complaints early.
So I flipped the default, added a missing fallback in the case the
client gives us a name when we're expecting a number, and tested.
And decided to keep the same parameter name as on the client after all,
since it really does do pretty much the same thing.
Comitting for 3.4 absent objections.
--b.
commit 3516a947e59fb635ddd5c42d70bd4274f61daa8a
Author: J. Bruce Fields <[email protected]>
Date: Thu Mar 22 16:07:18 2012 -0400
nfsd4: allow numeric idmapping
Mimic the client side by providing a module parameter that turns off
idmapping in the auth_sys case, for backwards compatibility with NFSv2
and NFSv3.
Unlike in the client case, we don't have any way to negotiate, since the
client can return an error to us if it doesn't like the id that we
return to it in (for example) a getattr call.
However, it has always been possible for servers to return numeric id's,
and as far as we're aware clients have always been able to handle them.
Also, in the auth_sys case clients already need to have numeric id's the
same between client and server.
Therefore we believe it's safe to default this to on; but the module
parameter is available to return to previous behavior if this proves to
be a problem in some unexpected setup.
Signed-off-by: J. Bruce Fields <[email protected]>
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 0d79a88..e4f84f0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1686,6 +1686,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
The default is to send the implementation identification
information.
+ nfsd.nfs4_disable_idmapping=
+ [NFSv4] When set to the default of '1', the NFSv4
+ server will return only numeric uids and gids to
+ clients using auth_sys, and will accept numeric uids
+ and gids from such clients. This is intended to ease
+ migration from NFSv2/v3.
objlayoutdriver.osd_login_prog=
[NFS] [OBJLAYOUT] sets the pathname to the program which
diff --git a/fs/nfsd/nfs4idmap.c b/fs/nfsd/nfs4idmap.c
index 9409627..69ca9c5 100644
--- a/fs/nfsd/nfs4idmap.c
+++ b/fs/nfsd/nfs4idmap.c
@@ -41,6 +41,14 @@
#include "nfsd.h"
/*
+ * Turn off idmapping when using AUTH_SYS.
+ */
+static bool nfs4_disable_idmapping = true;
+module_param(nfs4_disable_idmapping, bool, 0644);
+MODULE_PARM_DESC(nfs4_disable_idmapping,
+ "Turn off server's NFSv4 idmapping when using 'sec=sys'");
+
+/*
* Cache entry
*/
@@ -561,28 +569,65 @@ idmap_id_to_name(struct svc_rqst *rqstp, int type, uid_t id, char *name)
return ret;
}
+static bool
+numeric_name_to_id(struct svc_rqst *rqstp, int type, const char *name, u32 namelen, uid_t *id)
+{
+ int ret;
+ char buf[11];
+
+ if (namelen + 1 > sizeof(buf))
+ /* too long to represent a 32-bit id: */
+ return false;
+ /* Just to make sure it's null-terminated: */
+ memcpy(buf, name, namelen);
+ buf[namelen] = '\0';
+ ret = strict_strtoul(name, 10, (unsigned long *)id);
+ return ret == 0;
+}
+
+static __be32
+do_name_to_id(struct svc_rqst *rqstp, int type, const char *name, u32 namelen, uid_t *id)
+{
+ if (nfs4_disable_idmapping && rqstp->rq_flavor < RPC_AUTH_GSS)
+ if (numeric_name_to_id(rqstp, type, name, namelen, id))
+ return 0;
+ /*
+ * otherwise, fall through and try idmapping, for
+ * backwards compatibility with clients sending names:
+ */
+ return idmap_name_to_id(rqstp, type, name, namelen, id);
+}
+
+static int
+do_id_to_name(struct svc_rqst *rqstp, int type, uid_t id, char *name)
+{
+ if (nfs4_disable_idmapping && rqstp->rq_flavor < RPC_AUTH_GSS)
+ return sprintf(name, "%u", id);
+ return idmap_id_to_name(rqstp, type, id, name);
+}
+
__be32
nfsd_map_name_to_uid(struct svc_rqst *rqstp, const char *name, size_t namelen,
__u32 *id)
{
- return idmap_name_to_id(rqstp, IDMAP_TYPE_USER, name, namelen, id);
+ return do_name_to_id(rqstp, IDMAP_TYPE_USER, name, namelen, id);
}
__be32
nfsd_map_name_to_gid(struct svc_rqst *rqstp, const char *name, size_t namelen,
__u32 *id)
{
- return idmap_name_to_id(rqstp, IDMAP_TYPE_GROUP, name, namelen, id);
+ return do_name_to_id(rqstp, IDMAP_TYPE_GROUP, name, namelen, id);
}
int
nfsd_map_uid_to_name(struct svc_rqst *rqstp, __u32 id, char *name)
{
- return idmap_id_to_name(rqstp, IDMAP_TYPE_USER, id, name);
+ return do_id_to_name(rqstp, IDMAP_TYPE_USER, id, name);
}
int
nfsd_map_gid_to_name(struct svc_rqst *rqstp, __u32 id, char *name)
{
- return idmap_id_to_name(rqstp, IDMAP_TYPE_GROUP, id, name);
+ return do_id_to_name(rqstp, IDMAP_TYPE_GROUP, id, name);
}
On Thu, Mar 22, 2012 at 08:53:25PM +0000, Myklebust, Trond wrote:
> On Thu, 2012-03-22 at 16:47 -0400, J. Bruce Fields wrote:
> > By the way, I finally got around to looking at the server side.
> >
> > We don't have any way to negotiate with the client--we don't get an
> > error back if the name we return in a getattr reply isn't one the client
> > likes--so I don't think I can default the new behavior to "on" without
> > breaking existing setups.
> >
> > Other than that I think I'll just copy the client, module parameter and
> > all. That allows us to do the numeric case in-kernel and avoid
> > polluting our mapping cache with lots of "obvious" 123<->"123" mappings.
> >
> > (OK, maybe I shouldn't copy the same parameter name, though--even if it
> > works it might be confusing.)
>
> Does the idmapper do the right thing for numeric ids these days? If the
> older clients are running a newer idmapper that can deal with numeric
> ids, then even the legacy clients should be able to work cleanly.
If at all possible I really don't want to break clients, even if they
have an easy fix. (Or maybe I wasn't understanding what you were
suggesting.)
> Otherwise, there is also the alternative of making the whole thing a
> per-client export option...
Hm, maybe that'd be better.
We're currently mapping names to id's when we decode the xdr--before
we've looked up the export--but that's fixable.
--b.
On 03/22/2012 02:26 PM, J. Bruce Fields wrote:
> On Thu, Mar 22, 2012 at 09:01:12PM +0000, Myklebust, Trond wrote:
>> On Thu, 2012-03-22 at 16:53 -0400, Trond Myklebust wrote:
>>> Does the idmapper do the right thing for numeric ids these days? If the
>>> older clients are running a newer idmapper that can deal with numeric
>>> ids, then even the legacy clients should be able to work cleanly.
>>
>> If this isn't the case, then the older clients are broken anyway. The
>> server has always had the option of returning numeric ids if it has no
>> mapping from a uid/gid into an owner/group string.
>
> Hm, yes, but I was worried that the id<->name mapping might just be
> different on the two sides--but if that's so, and they were using
> auth_sys, then they likely already had problems.
>
> So, maybe we could default this to on.
>
> If that's the case then I'd rather not bother making this per export:
> just an option to get the server back to its previous behavior would
> seem enough.
>
> --b.
>
>> IOW: the only difference between older and newer clients should really
>> be that the newer ones handle numeric strings more efficiently without
>> requiring an upcall, and that the newer clients will also try to _send_
>> numeric ids in SETATTR calls.
>>
I was thinking about this too. Trond was making this clearer.
Could we have an on/off/auto option? on the server.
The auto option is start with off, and if the client
"_send_ numeric ids in SETATTR calls" then this client will start to be
treated as on.
Though now that I see it in writing it looks too complicated. Just a crazy
thought I had.
If you ask me I vote for default on, because where it makes a difference
from my experience with old Server the setup had a problem. Now all of a
sudden it will magically work. I fail to see an opposite scenario where
the brokenness was good, and now it will be bad.
Thanks
Boaz
>> --
>> Trond Myklebust
>> Linux NFS client maintainer
>>
>> NetApp
>> [email protected]
>> http://www.netapp.com
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
T24gVGh1LCAyMDEyLTAzLTIyIGF0IDE2OjUzIC0wNDAwLCBUcm9uZCBNeWtsZWJ1c3Qgd3JvdGU6
DQo+IERvZXMgdGhlIGlkbWFwcGVyIGRvIHRoZSByaWdodCB0aGluZyBmb3IgbnVtZXJpYyBpZHMg
dGhlc2UgZGF5cz8gSWYgdGhlDQo+IG9sZGVyIGNsaWVudHMgYXJlIHJ1bm5pbmcgYSBuZXdlciBp
ZG1hcHBlciB0aGF0IGNhbiBkZWFsIHdpdGggbnVtZXJpYw0KPiBpZHMsIHRoZW4gZXZlbiB0aGUg
bGVnYWN5IGNsaWVudHMgc2hvdWxkIGJlIGFibGUgdG8gd29yayBjbGVhbmx5Lg0KDQpJZiB0aGlz
IGlzbid0IHRoZSBjYXNlLCB0aGVuIHRoZSBvbGRlciBjbGllbnRzIGFyZSBicm9rZW4gYW55d2F5
LiBUaGUNCnNlcnZlciBoYXMgYWx3YXlzIGhhZCB0aGUgb3B0aW9uIG9mIHJldHVybmluZyBudW1l
cmljIGlkcyBpZiBpdCBoYXMgbm8NCm1hcHBpbmcgZnJvbSBhIHVpZC9naWQgaW50byBhbiBvd25l
ci9ncm91cCBzdHJpbmcuDQoNCklPVzogdGhlIG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIG9sZGVy
IGFuZCBuZXdlciBjbGllbnRzIHNob3VsZCByZWFsbHkNCmJlIHRoYXQgdGhlIG5ld2VyIG9uZXMg
aGFuZGxlIG51bWVyaWMgc3RyaW5ncyBtb3JlIGVmZmljaWVudGx5IHdpdGhvdXQNCnJlcXVpcmlu
ZyBhbiB1cGNhbGwsIGFuZCB0aGF0IHRoZSBuZXdlciBjbGllbnRzIHdpbGwgYWxzbyB0cnkgdG8g
X3NlbmRfDQpudW1lcmljIGlkcyBpbiBTRVRBVFRSIGNhbGxzLg0KDQotLSANClRyb25kIE15a2xl
YnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFwcA0KVHJvbmQuTXlrbGVi
dXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg==