Date: Tue, 21 Oct 2014 19:31:55 +0200 From: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> To: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) Message-ID: <5446988B.5020509@omnilan.de> In-Reply-To: <20141021134516.GA89872@brick.home> References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <54464405.4090207@omnilan.de> <20141021134516.GA89872@brick.home>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5446988B.5020509>