From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 17:32:14 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B44A1F8 for ; Tue, 21 Oct 2014 17:32:14 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 162BBCBD for ; Tue, 21 Oct 2014 17:32:13 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9LHWBSA057616 for ; Tue, 21 Oct 2014 19:32:11 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 77A3034FC; Tue, 21 Oct 2014 19:32:10 +0200 (CEST) Message-ID: <5446988B.5020509@omnilan.de> Date: Tue, 21 Oct 2014 19:31:55 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Stable Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <54464405.4090207@omnilan.de> <20141021134516.GA89872@brick.home> In-Reply-To: <20141021134516.GA89872@brick.home> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig49C07E4D95F90B2884A93F58" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 21 Oct 2014 19:32:11 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) 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: Tue, 21 Oct 2014 17:32:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig49C07E4D95F90B2884A93F58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Edward Tomasz Napiera=C5=82a's Nachricht vom 21.10.2014 1= 5:45 (localtime): =E2=80=A6 >> In my "real world" case, I dispense backup disks to win7 clients via i= SCSI. >> 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 privat= e >> data on the clients which use that backup-strategy, so no need for >> qualified identity checks or encryption needed). Even with any securit= y >> 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 actuall= y > 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. =E2=80=A6 } 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 =E2=80=A6 } 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:= =C2=BBThe goal of iSCSI discovery is to allow an initiator to find th= e targets to which it has access, =E2=80=A6=C2=AB =E2=80=9C=E2=80=A6 to which it has access=E2=80=9D 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... >> 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 somet= hing > 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). >> 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=E2=80=A6 Don't have docs handy. >> The FormFactor was more cosmetic, but in bigger environments I guess i= t >> 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 :-= ( 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: =C2=BBBy 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",=E2=80=A6=C2=AB 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 rejecte= d. 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 :-) 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 =20 + # buitlin special + #auth-group default { auth-type deny } + #auth-group no-authentication { auth-type none} + + 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 + } + 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 + } + } --------------enig49C07E4D95F90B2884A93F58 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRGmJkACgkQLDqVQ9VXb8jlowCgxDzQMaKILKhLugk7pMX/QKgS Cw4AoIoUu1cy0L5hN0yrVDwh1FZZ+N03 =p5qN -----END PGP SIGNATURE----- --------------enig49C07E4D95F90B2884A93F58--