Re: [et-mgmt-tools] [PATCH] Add VNC-Port setting whenvirt-managercreates VM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 


[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux