From owner-freebsd-stable@FreeBSD.ORG Tue Oct 21 13:45:24 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 E9C7A7E4 for ; Tue, 21 Oct 2014 13:45:24 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 6CE8CE8F for ; Tue, 21 Oct 2014 13:45:24 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id z11so996438lbi.41 for ; Tue, 21 Oct 2014 06:45:22 -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=xkkgjXzbIwnMug5gvsWEbyl3IuyOvnZqmRWkyJ6qpSA=; b=xA/ol/B5r0LOmNesgIY7bhdexvqBhc0ot8e7AB+92xoGk1dlMOObwQq+CJognAlRfz mUmE6lgo7fV3ctgISWO0hmBokSC2/kLniM/SSDOUetfEVt/qsKGRWpJKGRIYLXfIb7pI +uJajdniKV6+3vT6sHcyvIYSn+AXpiHomJOjJmEzuBjoC3TmMIyrtgaC+Q6buDRcSmhX rcx2e826awV/4cjUahF+xVmpHhNUqa+5nvygfMUIfidrbWlXSq0+1/qgnWyuvlQW9gSc 40fflzmJx8a9/RAZl0ZjSngODhkXpIcsdcaAFQN0Hux6TAyhb2cXwrIcAdHhozap891b VmBA== X-Received: by 10.152.204.76 with SMTP id kw12mr34150166lac.37.1413899121863; Tue, 21 Oct 2014 06:45:21 -0700 (PDT) Received: from brick.home ([79.184.115.52]) by mx.google.com with ESMTPSA id dq5sm4562948lbc.11.2014.10.21.06.45.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Oct 2014 06:45:20 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 21 Oct 2014 15:45:16 +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: <20141021134516.GA89872@brick.home> Mail-Followup-To: Harald Schmalzbauer , FreeBSD Stable References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <54464405.4090207@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54464405.4090207@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: Tue, 21 Oct 2014 13:45:25 -0000 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?