ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions)

[Edward Tomasz Napierała]

On 1021T1331, Harald Schmalzbauer wrote:
>  Bezüglich Edward Tomasz Napierała's Nachricht vom 21.10.2014 12:43
> (localtime):
> > On 1020T1035, Harald Schmalzbauer wrote:
> >>  Hello,
> >>
> >> I'm trying to move from istgt(1) to ctld(8), but it seems my setup isn't
> >> possible with ctld.
> >> Besides missing support for virtual-DVDs ('UnitType DVD' in istgt) and
> >> real ODD-devices ('UnitType pass' in istgt),
> > Yup, we don't implement virtual DVDs and passthrough.  Especially the
> > latter would be a nice feature to have.
> >
> >> I guess it's impossible to
> >> define multiple "portal-group"s, listening on the same socket, but with
> >> different "discovery-auth-group".
> >> The idea is, to present initiators only targets at discovery, which they
> >> are allowed to connect to.
> >> Am I missing something which could provide such selective discovery with
> >> ctld(8)?
> > I thought about it, but I don't like the way istgt does it.  By allowing
> > multiple portal groups to bind to a single address (portal), we would
> > introduce ambiguity as for which portal-group and associated
> > discovery-auth-group is being used.  On the other hand, a simplistic
> > approach of only showing targets with auth-group being the same
> > as discovery-auth-group for the portal probably wouldn't be very useful
> > in real-world cases.
> 
> Thanks a lot for your attention and the highly appreciated work on ctl[d]*!

Thanks :-)

> 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?

> 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?

> 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.

> If someone could point me to the meaning of option iscsiname?

That's an istgt option, right?