From patchwork Sat Jun 8 13:08:20 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 2692441 Return-Path: X-Original-To: patchwork-cifs-client@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id C5F3B3FC23 for ; Sat, 8 Jun 2013 13:08:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751513Ab3FHNIZ (ORCPT ); Sat, 8 Jun 2013 09:08:25 -0400 Received: from mail-gh0-f169.google.com ([209.85.160.169]:53423 "EHLO mail-gh0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751379Ab3FHNIY (ORCPT ); Sat, 8 Jun 2013 09:08:24 -0400 Received: by mail-gh0-f169.google.com with SMTP id r1so626041ghr.28 for ; Sat, 08 Jun 2013 06:08:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=YrNMyR0I2EvLljI6vJ/g9rhsiBmRboY0NMt5jPvM6/4=; b=TqDsZFaZiIzfx6f/1LrdI4M7EK57WC2iyA6n+K2d/QUe4QC6c5/4dUItU7Dt0RvSk7 FP4HpM4QKcb5hYrzlnQgBlix8P5Zz8MNb8gRb4b5/39LTiVhR4UXBCwuUVQVL+atT9pF K4P7kKrSkMPM1v/WVEw1TK0wC7y2FU7/Uh2MQKnwFHy/6u53j29QEA2QwyRJrF59x0UF BvbAlWDJYm7kVNWBuBfqWlir/gTnNhXkvPM3GWSDku2QSCtlblcdK7Ot8DRHJ4IwvKF8 uSD8mgVd+jsEEMEYgawssYy2GuCqLT+Or8pw/m6l+aHxMU9F+cuS7119e0Tc3q+Ao4cg ugQQ== X-Received: by 10.236.31.37 with SMTP id l25mr1135734yha.196.1370696903881; Sat, 08 Jun 2013 06:08:23 -0700 (PDT) Received: from tlielax.poochiereds.net ([2001:470:8:d63:3a60:77ff:fe93:a95d]) by mx.google.com with ESMTPSA id j64sm4268543yhj.25.2013.06.08.06.08.23 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 08 Jun 2013 06:08:23 -0700 (PDT) Date: Sat, 8 Jun 2013 09:08:20 -0400 From: Jeff Layton To: steve Cc: linux-cifs@vger.kernel.org Subject: Re: cifs-utils VFS errors Message-ID: <20130608090820.1f3bb0e2@tlielax.poochiereds.net> In-Reply-To: <1369860007.2278.19.camel@hh16.hh3.site> References: <51A32117.5030908@steve-ss.com> <20130528063525.1baeac8c@corrin.poochiereds.net> <1369744796.2769.8.camel@hh16.hh3.site> <20130528090142.36d5076e@corrin.poochiereds.net> <1369842745.3123.9.camel@hh16.hh3.site> <20130529144555.595ee5a4@tlielax.poochiereds.net> <1369860007.2278.19.camel@hh16.hh3.site> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Gm-Message-State: ALoCoQnMt8SOfFj04aMEofb3mMWh5yifgyZ8pJVM7B+CniqRHun93yo+ve+degj6e2+YuR5/ffuM Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org On Wed, 29 May 2013 22:40:07 +0200 steve wrote: > On Wed, 2013-05-29 at 14:45 -0400, Jeff Layton wrote: > > On Wed, 29 May 2013 17:52:25 +0200 > > steve wrote: > > > > > On Tue, 2013-05-28 at 09:01 -0400, Jeff Layton wrote: > > > > > How does this sound? > > > > > - I make a domain user called cifsuser with rfc2307 uidNumber and > > > > > gidNumber: > > > > > uid=3000025(cifsuser) gid=20513(Domain Users) groups=20513(Domain Users) > > > > > > > > > > - I mount like this: > > > > > sudo kinit cifsuser > > > > > mount -t cifs //oliva/users /mnt -osec=krb5 > > > > > (just tried it: fine) > > > > > > > > > > -I stick cifsuser in the keytab and kinit -k it in a cron every few > > > > > hours or so to keep it alive. > > > > > > > > > > Thanks so much for your time, > > > > > Steve > > > > > > > > > > > > > That sounds reasonable. Assuming that you don't actually do anything on > > > > the mount as root, then you can give "cifsuser" very limited privileges > > > > here too, essentially acting as a "squashed" user like under NFS. > > > > > > > > Also, there's no need to do this crontab stuff either. If you mount > > > > with "-o sec=krb5,username=cifsuser" then cifs.upcall will be able to > > > > just use /etc/krb5.keytab without you needing to do anything special. > > > > > > > > > > > > > Hi > > > OK. Nearly done. I now have the automounter working: > > > /etc/auto.users > > > * -fstype=cifs,rw,sec=krb5,username=cifsuser,multiuser ://oliva/users/& > > > > > > It works fine except I have 2 keytabs per client. > > > /etc/krb5.keytab > > > produced by > > > net ads join > > > It contains the host/client and MACHINE$ keys > > > and > > > /etc/cifs.keytab > > > produced the DC and copied to the clients which contains the cifsuser > > > keys. > > > > > > Question: will cifs only look in /etc/krb5.keytab? Can I get it to look > > > at /etc/cifs.keytab instead? OK, I can ktutil merge them but. . . > > > > > > Thanks for your patience. > > > > > > > > > > Yes, it currently only looks at /etc/krb5.keytab. It probably wouldn't > > be very hard to add a new command-line option to give it an alternate > > one if that helps. > > > > I do have a question here though. Why are you bothering with the > > automounter at all? Why not instead just mount //oliva/users via fstab > > at the point where auto.users is currently mounted? > > > > That should give you the same effect with a much smaller mount table > > and no automounter overhead. Something like this in /etc/fstab ought to > > do it: > > > > //oliva/users /path/to/top/of/users/dir cifs sec=krb5,username=cifsuser,multiuser 0 0 > > > Hi > Without the automounter, the fileserver grinds to a halt after around 20 > users connect. A lot of our hardware is around 10 years old. > None of that should matter. The cifs client aggressively shares connections, so the server should see little difference either way in how the network traffic looks whether you have multiple mounts like this or a single multiuser mount. The only thing I can think of that would be different would be that the automounter might umount on a shorter schedule, and hence you might end up with fewer SMB sessions to the server. If that's the case though, then you're likely to see the same problems with the autofs setup eventually. You just need a particularly busy period of the machine... In any case, if you're seeing your server grind to a halt, then I think you'd be well-advised to try to figure out why that is. autofs shouldn't really be fixing anything here. > Adding an option to select a different keytab for mount.cifs would be > great. e.g. a bit like the -t in: > kinit -k cifsuser -t /etc/cifs.keytab > Adding such an option is reasonably trivial. Does the following patch work for you? If it does, it'll need a manpage update too. --------------------[snip]---------------------- [PATCH] cifs.upcall: allow users to specify dedicated keytab on command-line Currently cifs.upcall only looks at the default system keytab (/etc/krb5.keytab). It's often the case however that a dedicated keytab is desirable. Allow users to set one on the command-line. Signed-off-by: Jeff Layton --- cifs.upcall.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/cifs.upcall.c b/cifs.upcall.c index 6c0b9de..5a6c7d7 100644 --- a/cifs.upcall.c +++ b/cifs.upcall.c @@ -805,13 +805,14 @@ lowercase_string(char *c) static void usage(void) { - fprintf(stderr, "Usage: %s [-k /path/to/krb5.conf] [-t] [-v] [-l] key_serial\n", prog); + fprintf(stderr, "Usage: %s [ -d /path/to/keytab] [-k /path/to/krb5.conf] [-t] [-v] [-l] key_serial\n", prog); } const struct option long_options[] = { {"krb5conf", 1, NULL, 'k'}, {"legacy-uid", 0, NULL, 'l'}, {"trust-dns", 0, NULL, 't'}, + {"dedicated-keytab", 1, NULL, 'd'}, {"version", 0, NULL, 'v'}, {NULL, 0, NULL, 0} }; @@ -839,11 +840,14 @@ int main(const int argc, char *const argv[]) openlog(prog, 0, LOG_DAEMON); - while ((c = getopt_long(argc, argv, "ck:ltv", long_options, NULL)) != -1) { + while ((c = getopt_long(argc, argv, "cd:k:ltv", long_options, NULL)) != -1) { switch (c) { case 'c': /* legacy option -- skip it */ break; + case 'd': + keytab_name = optarg; + break; case 't': try_dns++; break;