Hi, Dan The following issue is not Authenication (and not Security) issue. Just for usability issue. Shigeki just want to add a option for fixed port allocation. (addition with your suggested dynamic port.) I would be appreciated if you consider this issue. Thanks Atsushi SAKAI "S.Sakamoto" <fj0588di@xxxxxxxxxxxxxxxxx> wrote: > I compile my opinion simply. > - Same as virt-install, > I want to give a user the right that can select auto or fix in virt-manager. > - At first, the authentication has nothing to do with a function that fix port number. > > > Reason: > > it would be desirable to only open up a port when explicitly needed, > > and not require the admin to do any work. > I think so too. > but, as follows, > I think that need to fix a port necessarily comes out. > > For example, > When I have already used 5900-5920 about a port number > (Use except vnc or use in vnc except virt-manager), > > Need to review a system using 5900 for comes out, > when I install a guest with auto selection newly. > With it, a review of the whole system may occur. > In the case of an example, > a manager will assign it to a new guest anything other than 5900-5920. > > > Because a user can do operation & management that include setting of a port with virt-install, > I think that we should give a user the right to be able to do operation & management with virt-manager. > > > After having stood on these, > Which thinks it to be big with an advantage when there is a function of fixed port selection > and an advantage when there is not it? > > > Thanks, > Shigeki Sakamoto. > > <200706081441.GID09350.90EGJK69@xxxxxxxxxxxxxxxxx> の、 > "Re: [et-mgmt-tools] [PATCH] Add VNC-Port settingwhenvirt-managercreates VM" において、 > ""S.Sakamoto" <fj0588di@xxxxxxxxxxxxxxxxx>"さんは書きました： > > > Hi, Dan > > > > Would you give me a comment? > > > > > > --- The summary of last time --- > > The user who wants to manage GUEST from port number 9000 does not use the virt-manager > > if it cannot choose a port at the time of use when he introduce GUEST. > > > > Even if the virt-manager is no matter how convenient, > > this user will avoid use of the virt-manager because it forces him to allocate from 5600- . > > > > How do you think about this problem? > > > > I think that this user is not niche! > > -------------------------------- > > > > thanks, > > Shigeki Sakamoto. > > > > > > <200705311822.JEJ86930.0JK9G96E@xxxxxxxxxxxxxxxxx> の、 > > "Re: [et-mgmt-tools] [PATCH] Add VNC-Port setting whenvirt-managercreates VM" において、 > > ""S.Sakamoto" <fj0588di@xxxxxxxxxxxxxxxxx>"さんは書きました： > > > > > Hi > > > > > > An advantage of the fixed port which I want to insist on is "A user can choose an arbitrary port.". > > > Neither remote-connection nor authentication matters particularly. It is a story before it. > > > The reason why this user comes to need choice of a fixed port is as follows. > > > > > > > > > If an user absolutely use the port number from 5900, either does not surely matter. > > > But, > > > for example, > > > when the port number 5900-5920 is used by other uses, > > > when there is a user hoping that I manage a port number by use to assign from 9000, > > > > > > A fxed port selection mode is necessary, because there is these situation. > > > (The person who does not need a fixed port should choose an auto selection mode.) > > > Any users will not hope to change other designs to use it for auto selection. > > > > > > > > > Thanks, > > > Shigeki Sakamoto. > > > > > > > > > > > > > On Tue, May 29, 2007 at 04:44:15PM +0900, S.Sakamoto wrote: > > > > > Hi, Dan > > > > > > > > > > Thanks for your comment. > > > > > > > > > > > It will prove unreliable in practice, because even if you > > > > > > fix a particular guest on port 5905, any other guest doing dynamic VNC port > > > > > > assignment may choose this port before the hardcoded guest starts. > > > > > This situation is surely thought. > > > > > But, I think that problem is solved > > > > > if it performs a repetition check of a port number in virt-inst. > > > > > When it is this situation, at first, > > > > > examine the port number that all other guests use when it starts a guest. > > > > > Next, If the port number is fixed and repetition, > > > > > output a message. [e.g."Repetition. Set a different port number."] > > > > > (However, there is not a function setting a port for an existing guest now. > > > > > If it is necessary at the same time, > > > > > I make 'check of repetition' and 'function setting a port for an existing guest'.) > > > > > > > > > > > It is not going to be easy for virt-manager to do validation of this port number > > > > > > either, since in the near future virt-manager may well be running remotely > > > > > > from the host. > > > > > If it adds a revision to libvirt side to get a port number from the information that acquired from xend, > > > > > the acquisition of a port number will be easy. > > > > > > > > > > > this is a very small niche usecase > > > > > I do not think so. and I think that there is a person to need surely. > > > > > Because, I think that it can perform the prevention / maintenance > > > > > by the pair of guest and port-number are managed. > > > > > For example, The person who thinks about maintenance for the port which opened out > > > > > had better be a fixed port number. > > > > > If it does't know whether it has already opened or it will open out from now on, > > > > > it will become difficult to deal with possibility of attack to an opening port. > > > > > Therefore, > > > > > the user who wants to open only a specific port for a firewall needs to fixed port number. > > > > > And, even if it can get a dynamic port from remote connection in the future, > > > > > he needs a fixed port number at the time of remote connection too, > > > > > because he wants to connection with only a specific port. > > > > > > > > There's two possibilities to consider: > > > > > > > > a. The admin of the Dom0 permanently opens up a range of ports (eg 5900->5920) to allow > > > > upto 20 vms to have their console accessed at any time. In this case, whether you > > > > use fixed or dynamic ports per VM, you still need 20 ports open, to run 20 consoles. > > > > > > > > b. The admin of the Dom0 only opens specific ports for short periods of time. In this > > > > case the admin will have to lookup what port corresponds to a VM, so it doesn't matter > > > > whether we're using fixed or dynamic ports, the admin still has same amount of work > > > > to lookup a port. > > > > > > > > So, I still don't see that using fixed ports in virt-manager has any benefit for the > > > > administration POV. > > > > > > > > Neither of these two options are entirely satisfactory though - it would be desirable > > > > to only open up a port when explicitly needed, and not require the admin to do any > > > > work. One might even suggest that libvirt should have some form of API to let the > > > > remote user request access to the cosnole - authenticated of course > > > > > > > > > > > > virDomainAllowConsole(virDomainPtr, const char *ipaddr); > > > > virDomainDisallowConsole(virDomainPtr, const char *ipaddr); > > > > > > > > Calling either of these functions would add neccessary iptables rule to allow > > > > access to the console for that particular domain, from the specified ip address. > > > > When the virConnectPtr object was closed, then any rules would also automatically > > > > be removed. > > > > > > > > This would allow virt-manager to securely request access to the console without > > > > needing permanent iptables rules. > > > > > > > > These's probably quite a bit more to think about wrt to iptables, consoles > > > > and seecure authentication. In the very near future libvirt will have the > > > > support for remote management merged and we'll be in a position to experiment > > > > with these ideas for real. So I don't think we want to add support for fixed > > > > port numbers in the virt-manager wizard until we've tried out some of these > > > > ideas. > > > > > > > > Regards, > > > > Dan. > > > > -- > > > > |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| > > > > |=- Perl modules: http://search.cpan.org/~danberr/ -=| > > > > |=- Projects: http://freshmeat.net/~danielpb/ -=| > > > > |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| > > > > > > > > > > _______________________________________________ > > > et-mgmt-tools mailing list > > > et-mgmt-tools@xxxxxxxxxx > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/et-mgmt-tools
