From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 11:31:28 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 67825721 for ; Tue, 21 Oct 2014 11:31:28 +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 E3861D25 for ; Tue, 21 Oct 2014 11:31:27 +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 s9LBVOcJ053427 for ; Tue, 21 Oct 2014 13:31:24 +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 D80C2341F; Tue, 21 Oct 2014 13:31:23 +0200 (CEST) Message-ID: <54464405.4090207@omnilan.de> Date: Tue, 21 Oct 2014 13:31:17 +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> In-Reply-To: <20141021104308.GA5990@brick.home> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig42D225F1D00A3CAB209D0385" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 21 Oct 2014 13:31:24 +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 11:31:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig42D225F1D00A3CAB209D0385 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= 2: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 wit= h >> different "discovery-auth-group". >> The idea is, to present initiators only targets at discovery, which th= ey >> are allowed to connect to. >> Am I missing something which could provide such selective discovery wi= th >> ctld(8)? > I thought about it, but I don't like the way istgt does it. By allowin= g > 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]= *! In my "real world" case, I dispense backup disks to win7 clients via iSCS= I. 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. 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. 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 it can be useful if you have multiple targets available, choosing the better fitting backend-pool e.g. If someone could point me to the meaning of option iscsiname? Thanks a lot, -Harry --------------enig42D225F1D00A3CAB209D0385 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) iEYEARECAAYFAlRGRAsACgkQLDqVQ9VXb8gzCQCfQNFezkkPkMaf5icVtm3VRWVg /xcAnA41TJ+dlGLCGkYivDWeGGhcTYSr =IYyz -----END PGP SIGNATURE----- --------------enig42D225F1D00A3CAB209D0385--