From owner-freebsd-stable@FreeBSD.ORG Wed Oct 22 10:58:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14B777ED for ; Wed, 22 Oct 2014 10:58:11 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 883A4EB0 for ; Wed, 22 Oct 2014 10:58:10 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id q1so2672345lam.32 for ; Wed, 22 Oct 2014 03:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Wq/qhYgY7HXvJpZWgqdv+gc38IMZ1bU6aLsanwbA/hs=; b=h2IwImVDlH3RqMbzmIeVKs2VUJAeqTSZJcXMXWrkPfNbiNxcJBG0TvKuPjDoVwCvTi eTkXe59MbTkmGtDv5KTX1LsmRXW56GjsC5PC0n4DcX3N9KM+8qtv2j5DjKFzmw7zl+1l Dke0S80yTjyAwrXl7anjw8q1Rc3KCbFYD2WeRgdO7q2sv31ylVF1aFDhe1eKzyKgTHEn FleT2OzY64OfnvaJ4DeEaeLEZZNIeRPvAFlTymKlN1QcFl0kB/GnfvAb8jdwhiuUlrj4 m0C1xqx2tNDWXLQmDIu0FkHZ2RuJHmAx6Gf/jKKDFWfGo/T8+1vIY0ZfxNfkMK2JGxlc DA/g== X-Received: by 10.152.120.199 with SMTP id le7mr6971718lab.67.1413975488417; Wed, 22 Oct 2014 03:58:08 -0700 (PDT) Received: from brick.home (aeaa193.neoplus.adsl.tpnet.pl. [79.186.0.193]) by mx.google.com with ESMTPSA id ro7sm5654653lbb.14.2014.10.22.03.58.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 03:58:07 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Wed, 22 Oct 2014 12:58:04 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Harald Schmalzbauer Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) Message-ID: <20141022105804.GB5415@brick.home> Mail-Followup-To: Harald Schmalzbauer , FreeBSD Stable References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <54464405.4090207@omnilan.de> <20141021134516.GA89872@brick.home> <5446988B.5020509@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5446988B.5020509@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 10:58:11 -0000 On 1021T1931, Harald Schmalzbauer wrote: > Bezüglich Edward Tomasz Napierała's Nachricht vom 21.10.2014 15:45 > (localtime): > > … > >> In my "real world" case, I dispense backup disks to win7 clients via iSCSI. > >> I liked the possibility to limit target-discovery-results, because > >> curious people, garnated such extra resources, weren't able to see who > >> else was granted this extra resource (by definition, there's no private > >> data on the clients which use that backup-strategy, so no need for > >> qualified identity checks or encryption needed). Even with any security > >> mechanisms active, two consumers (some dozen in my case) of the same > >> portal know about the other. That's one example where this feature was > >> useful for me. > > So basically, each target has a different user/password pair, and > > during discovery the target only returns those targets that can actually > > be accessed using that user/password? > > In general, yes, that's what I did with istgt. But I omitted chap > authentication, intead I'm just checking initiator-name/adress. > So speaking in ctl.conf, I would love to see an extension in the target > Context, which influences discovering results, maybe like > > target iqn.2012-06.com.example:target0 { > SendTarget on-discover | access-granted # access-granted only has > effect on assigned portal-group(s), which have 'target-filter' enabled. > … } > > I guess that would need quiet a lot of extra checks added to existing > discovery-response functions, so maybe it would make sense to > selectively enable/disbale this extra check at portal-group Context in > the first place, maybe like > > portal-group lan0 { > target-filter on | off > … } I think I like the second one better. Except I'm not sure about "target-filter" name. "authorized-targets-only" perhaps? > I just had a look at rfc3721, to find a suitable name for the > 'SendTarget' config option I suggested here > (http://www.ietf.org/rfc/rfc3721.txt, Page 12, 3.b). > > Quote of the first sentence in chapter 3, describing the iSCSI discovery: > »The goal of iSCSI discovery is to allow an initiator to find the > targets to which it has access, …« > > “… to which it has access” sounds to me like the filtered SendTarget > behaviuor should be default, but I haven't read the complete docuemtn > nor am I native english speaker... Thought about this as default too. Question is, wouldn't it confuse users? On the other hand, _not_ doing it by default could be confusing too, just in another way. I kind of have a prototype for this. Could you test patches against 11-CURRENT, when I have them ready? > >> Another one actually is (since not implemented in ctld, yet?) with > >> virtual DVDs. If you provide 50 DVDs at one portal, it's confusing if > >> any initiator needs to select from the complete list. > > In this case do the returned targets depend on authentication, or something > > else, eg. a static list defined in config? > > The returned targets are still access restricted, by authentication or > any initiator-match rule (name, address, both). Ok. > >> I'd like to point to two options I'm missing: > >> option RPM > >> option FormFactor > >> And another one I don't know/understand: > >> option scsiname > >> > >> Missing resp. wrong reported option RPM leads to identification as SSD > >> with ESXi initiators. I don't remember what defines a SSD vs. HDD, I > >> think it was a threshold of something about 400? Or was it 0? I think I > >> read the former… Don't have docs handy. > >> The FormFactor was more cosmetic, but in bigger environments I guess it > >> can be useful if you have multiple targets available, choosing the > >> better fitting backend-pool e.g. > > Hm, ok. > > Thanks for your attention again! > > > >> If someone could point me to the meaning of option iscsiname? > > That's an istgt option, right? > > Sorry, haven't made clear: ctl.conf(5) references ctladm(8) for possible > "name value" pairs for the "option" option in the target Context. > In ctladm's OPTIONS section, I can find most options I ever used (and in > my case mandatory options like "product") besides to above mentioned two > (RPM and FormFactor), and also some additional I haven't used. > There's "scsiname" listed. I don't even understand the meaning of that :-( Ah. AFAIK it's just a "device name", at SCSI level. Basically, there are several kinds of identifiers a SCSI device (accessed over iSCSI or some other transport) can return when asked. There is NAA, EUI, and just text, which I believe is the "scsiname". > Hope you don't mind if I add another question: > > In ctl.conf(5), section "portal-group Context", under the description > for 'discovery-auth-group', one can read: > »By default, portal groups that do not specify their own auth > settings, using clauses such as chap or initiator-name, are assigned > predefined auth-group "default",…« > I tried to define 'initiator-name' under portal-group Context, but that > didn't work. I think I got an error message and config-reload was rejected. Hm, yeah, it's a documentation error. You can only use discovery-auth-group. > The reason I tried to not use a predefined auth-froup was, that I get a > warning it I define a auth-group and don't assign it to any target, > instead using it as 'discovery-auth-group' only. Not really a problem, > prpbably not even worth a PR/bugzilla report, but wanted to mention it > here :-) _Every_ problem is worth reporting. I've just fixed the spurious warning, btw. ;-) > And, not enough yet, I'd like to suggest a extension to the examples > section of ctl.conf(5): > > --- /tmp/ctl.conf.sample.orig 2014-10-21 19:11:46.000000000 +0200 > +++ /tmp/ctl.conf.sample 2014-10-21 19:25:28.000000000 +0200 > @@ -1,5 +1,16 @@ > pidfile /var/run/ctld.pid > > + # buitlin special > + #auth-group default { auth-type deny } > + #auth-group no-authentication { auth-type none} What is the above for? > + > + auth-group example1 { > + auth-type none > + initiator-name "iqn.2012-06.com.example:initiatorhost1" > + initiator-name "iqn.2012-06.com.example:initiatorhost2" > + initiator-portal 192.0.2.0/24 > + } This is to show ohw "auth-type none" should be used, right? I like it. > + > auth-group example2 { > chap-mutual "user" "secret" "mutualuser" "mutualsecret" > chap-mutual "user2" "secret2" "mutualuser" "mutualsecret" > @@ -41,3 +52,13 @@ > option foo bar > } > } > + > + target iqn.2012-06.com.example:target1 { > + auth-type none > + initiator-name "iqn.2012-06.com.example:initiatorhostname0" > + initiator-portal [2001:DB8::de:ef] > + portal-group example2 > + lun 0 { > + path /dev/zvol/example_1 > + } > + } This one, however, looks a little redundant.