Talk:Problematic Programs

I stronly suggest we rename this page to something else. I have become embroiled in a discussion with a customer and their development team who do not fully understand the concept of vservers, and the management team is not strong enough to discern quality of all technical arguments. The developer is using the title of this particular page as an indication that there are "problems with vservers and we shouldnt use them".

The first line of the page does outline how its most often not vserver's fault, but the name of the page seems to summarize a point of view about vservers thats detrimental.

Perhaps we should rename it to soemthing like "programs needing vserver-specific configuration" or the like. Hard to find a nice two word one like "problematic programs", but the name suggests more negative aspects than it should.

-- Math

The way that I see it, "Problematic Programs" means that the programs are problematic, not Linux-VServer itself ;). A new title would still be good, but "Programs needing VServer-specific configuration" is probably too long for a page title.
-- Daniel15 (^Talk/_Contribs) 09:30, 4 February 2007 (CET)

How about "Issues with 3rd party software"? --Guy- 22:13, 4 February 2007 (CET)

127.0.0.1 issues

I have suggested on the FAQ page that How do i install nagios-plugins on a Gentoo guest? be merged into this topic. During my irc conversations with Bertl today he said he would rather see these suggestions removed altogether.

At the least I would like to update this topic some more to give people more understanding on the topic. Perhaps a full page ought to be created and dedicated to giving the scoop on using localhost and on the loopback interface in general and in vserver. That way more right information is presented than wrong information. Some notes for that potential page, or for those who want to know what is being discussed about this topic:

• Most apps have worked fine with all versions of vserver. If the app looked up the 'loopback' address interface via the localhost name, they always worked because by default the vserver tools would configure that to be the same as your first configured ip address.

• Some apps are hard-coded to use 127.0.0.1 instead of resolving localhost. These programs had problems under versions of vserver before 2.3 unless you exposed 127.0.0.1 to the guest. This action would have security implications and run time problems you may not have forseen, such as having two guests both try to bind their http server to 127.0.0.1:80 via their 0.0.0.0:80 binding.

• With the 2.3.x vserver kernel patch forward and back mapping of 127 address was available. You can set this via the nflags LBACK_REMAP capability. It is probably enabled on by default on your system. This presents to each guest the 127.0.0.1 address without you adding an interface. It virtualizes the interface into 127.x.y.1 where x.y are derived from your security context so the 127.0.0.1 traffic your guest deals with is separate from another guest. If you wish to allow all hosts to share the 127 network to communicate, that is also an option in 2.3.x by removing the LBACK_REMAP flag and adding the LBACK_ALLOW flag. At that point you can start running into the 0.0.0.0:x issue and may want to configure your own 127.x.y.1 scheme.