This thread is to track improvement that could be imported from the robvdl fork, otherwise we cannot simple cherry-pick commits due to his deep app rework.

After using the interface to clone a container (the switch is unlabeled), the Root FS is now listed as "overlayfs:/storage/lxc/templatecontainer/rootfs:/storage/lxc/newcontainer/delta0". The container can be launched and works properly, but attempting to change the container settings using the interface will not succeed, as the interface does not allow the Root FS field to contain the new "overlayfs:" storage.

Following scenario:

 ______        _______         ______ 
| User | <--> | Host  | <-->  | lwp  |
|      |   443| nginx |   5000|      |    
 ------        -------         ------ 
             Reverse Proxy

Since lwp is not the only HTTPS service, it is desirable to run it with a prefix such as example.com/lxc, otherwise one must have a certificate for a subdomain or run lwp on a different port.

It would be nice if one can configure lwp to run with a specific URL prefix such as '/lxc', otherwise most ressource URLs are broken (e.g. those to example.com/lxc/static/* are example.com/static/*).
I realize that this is fixable by rewriting all URLs with rewrite rules in the reverse proxy, but this seems like a workaround and not a solution.

Thoughts? Is this already possible and I didn't find the config option?

@claudyus, you've done a fantastic job with this fork. You've added so many features, it qualifies as a project on it's own. If @Googley is busy and unable to pull these changes, I recommend renaming the project to something unique so new LXC users can find & use this project instead as it's compatible with 1.0+. Of course, you'd still give credit to the original.

Some name ideas to get you going:

• LXC Virt manager (lxc-vm)
• LXC GUI (lxcg / lxg)
• LXC Manager (lxcm)

And @Googley , if you haven't yet, you should point users on your website to this link for 1.0+ which is default in all new Linuxes..

Steps to reproduce;

• Have any container you haven't touched with LWP, let's call it 'pristine' (so that config is default, not what's saved by LWP)
• Open LWP settings page of pristine, press Apply
• Currently assigned ipv4 address gets written into lxc config file as e.g.: 'lxc.network.ipv4 = 10.0.3.81'
• reboot container

At this stage under some conditions I haven't fully grasped yet LXC may assign the ipv4 address twice because the network hasn't been clearly defined;
10.0.3.81/24
10.0.3.81/8

Which proceeds to add a route;
10.0.0.0/8 0.0.0.0

Which causes all sorts of interesting issues, for example port forwards not working if your outer network is also inside 10.0.0.0.
The proper solution is to define the network properly in lxc config as: 'lxc.network.ipv4 = 10.0.3.81/24' Getting the right network oughta be easy, it's defined in /etc/default/lxc-net;
LXC_NETWORK="10.0.3.0/24"

It's LXC that causes all the pain for reasons I don't know but mitigating it is as easy as using the full format when saving the ip address in the config.

Hi,

If I create a new CT named "test_ct", I can no longer change any settings, or even re-apply current settings. After pressing "Apply" at the bottom, the page scrolls to the top, highlights the hostname box in Red and says "Please match the requested format".

Hi,

After I create a CT, I cannot change it's hostname on the edit page. The change is discarded.

In 0.7, when I hit "Backup CT" and configure a local or nfs backup, but don't slide the switch to ON, lwp redirects to http://127.0.0.1:5000/action/backup-container and shows the following text:

Bad Request
The browser (or proxy) sent a request that this server could not understand.

If I slide to ON, then the backup takes place as expected.

Fedora 21 is out, and their server offering is pretty competitive with Ubuntu (Up to date RPM packages + modernization)

I'm going to spin up a Fedora 21 VM to see if I can get this running there with minimal effort :-)

Something went wrong when upgrading to 0.7-4

Setting up lwp (0.7-4-gd5c924e) ...
start: Job failed to start
invoke-rc.d: initscript lwp, action "start" failed.
dpkg: error processing package lwp (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 lwp

Using htpasswd, seen after login

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1836, in __call__
    return self.wsgi_app(environ, start_response)
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1820, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1403, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/lib/python2.7/site-packages/lwp-git_-py2.7.egg/lwp/views/auth.py", line 80, in login
    if check_htpasswd(HTPASSWD_FILE, request_username, request_passwd):
  File "/usr/lib/python2.7/site-packages/lwp-git_-py2.7.egg/lwp/utils.py", line 171, in check_htpasswd
    return hmac.compare_digest(crypt.crypt(password, htpasswd), htpasswd)
TypeError: 'NoneType' does not have the buffer interface

If I add an additional lines to the container's config as described here http://www.boxtricks.com/multiple-network-interfaces-lxc-container/, LWP throws an Internal Server Error.

Multiple bridges are very useful when there's a br0 for public IPs (for example), and lxcbr0 for local IPs.

We should handle these type of config files without throwing an error.

Installed 0.7 from the deb file on Ubuntu. It didn't install a service, so I ran it with
$ lwp

Here's the initial output
Auth type: database
Running on http://127.0.0.1:5000/
Restarting with reloader
Auth type: database`

When I access a webpage, I don't see any bootstrap themes loaded and here's the output in console:

127.0.0.1 - - [13/Dec/2014 22:50:47] "GET /static/bower/bootstrap/bootstrap/css/bootstrap.min.css HTTP/1.1" 404 - 127.0.0.1 - - [13/Dec/2014 22:50:47] "GET /static/bower/bootstrap/bootstrap/css/bootstrap-responsive.min.css HTTP/1.1" 404 - 127.0.0.1 - - [13/Dec/2014 22:50:47] "GET /static/bower/bootstrap-switch/build/css/bootstrap2/bootstrap-switch.min.css HTTP/1.1" 404 - 127.0.0.1 - - [13/Dec/2014 22:50:47] "GET /static/bower/jquery/jquery.min.js HTTP/1.1" 404 - 127.0.0.1 - - [13/Dec/2014 22:50:47] "GET /static/bower/bootstrap/bootstrap/js/bootstrap.min.js HTTP/1.1" 404 - 127.0.0.1 - - [13/Dec/2014 22:50:47] "GET /static/bower/jqBootstrapValidation/dist/jqBootstrapValidation-1.3.7.js HTTP/1.1" 404 - 127.0.0.1 - - [13/Dec/2014 22:50:47] "GET /static/bower/bootstrap-switch/build/js/bootstrap-switch.min.js HTTP/1.1" 404 -

Possibly because of code reorg?

pre-release to fix

Preparativi per estrarre .../lwp_0.6-61-gadff84e_all.deb...
Estrazione di lwp (0.6-61-gadff84e) su (0.6-34-gbea07d8)...
Configurazione di lwp (0.6-61-gadff84e)...
Installazione della nuova versione del file di configurazione /etc/lwp/lwp.example.conf...
 * Auth type: database
Traceback (most recent call last):
  File "/usr/bin/lwp", line 12, in <module>
    from lwp.views import main, auth, api
  File "/usr/lib/python2.7/dist-packages/lwp/views/main.py", line 20, in <module>
    BUCKET_HOST = config.get('buckets', 'buckets_host')
  File "/usr/lib/python2.7/ConfigParser.py", line 607, in get
    raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'buckets'
lwp start/running, process 8079
Elaborazione dei trigger per ureadahead (0.100.0-16)...
ureadahead will be reprofiled on next reboot

I'm trying to access the container, which has debian installed.
What is the password for that? Also what are the passwords for others guest OS?
I use root/root, but not working.

edit.html has an h3 with a </small> end tag, but there is no <small> start tag

Hi,

I don't know if I have overlooked a configuration parameter, but is there already a possibility to create/manage a container with btrfs as backing store?
I can only choose between directory and LVM.

Thanks and best regards
BrooklynFFM

ubuntu 14.04
lxc already installed and used
installed using instructions at claudyus/lxc-web-panel
point browser at 127.0.0.1:5000
and I see loging screen
try to login w/default ID and password and immediately get 500 Internal Server error ?

This is on Ubuntu 14.04
If you run it manually, via:
/usr/bin/python /srv/lwp/lwp.py
and then do:
ps aux | grep lwp
You'll see that there is only one instance of the process

However, if you do:
service lwp start
you'll see 2 instances of it. This causes an issue when you do
service lwp stop
as that only stops the first one.

The original lwp doesn't exhibit this behavior, and the /etc/init.d/lwp is the same between your version and that one, so it must be some property of lwp.py

When you save or update the bucket token of a container, it always does an insert.

What it should be doing, is if you change a containers bucket token, is do an update on the existing record.

I already fixed this in my version, but I am using SQLAlchemy.

I'll try to provide more details and a better report later, but I thought you might want to take a look at this:

I'm on Ubuntu 14.04 host, using Ubuntu 14.04 containers running on lxc 1.0.3

It seems like if I edit a container in any way via LWP, the eth0 inside the container doesn't come up right on the next reboot/lxc-start. I notice that the layout of the config file is pretty drastically different before and after the container is edited by LWP, and I'm wondering if there might be some new config file syntax in 1.0 that LWP is lacking.

Again, I'll try and look closer and give more reproducible results tomorrow.

I had LXC Web Panel 0.2 running but upgraded to Jessie including most recent versions:

Package: lxc
Version: 1.0.4-3

Package: python-flask
Version: 0.10.1-2

Thing is that this fork is very much slower than the original one, it sometimes takes a minute to show the initial screen of all machines found (which are ~50).

,-- config:
[global]
address = 0.0.0.0
port = 80

debug = True

secret_key = {key}

ssl = False
pkey = mykey.key
cert = mykey.cert

auth = database

buckets = false

[database]
file = lwp.db

[session]
time = 10

[overview]
partition = /

[storage_repository]

[ldap]

[buckets]
`--

On Chrome at least this means that you cannot click on the left half of the create container button, but the right half is fine.

A quick inspection shows the h3 is overlapping the button, that is why. Making the h3 not quite as wide should fix this.

Whats the proper way about uinstalling this panel? Unfortunately it just makes to many changes to my configs that I have to edit manually because i use multiple interfaces and and bridged networking.

I discovered this while making the network form into WTForm, but it exists in this version of LXC Web Panel as well..

Saving network configuration is currently updating the config file: /etc/default/lxc

However, then when the page reloads, the old values still show, why? I looked into this, and it is because the get_net_settings() function will read the config from /etc/default/lxc-net instead (which appears to be the correct one), then /etc/default/lxc as fallback if it doesn't exist. I think this is ok, but saving network settings should probably be updating /etc/default/lxc-net, not /etc/default/lxc, at least on Ubuntu.

I am not sure what other distros do, but it appears the config settings should be saved in /etc/default/lxc-net instead.

If I attempt to delete a container which has cloned containers based on it's snapshot, lwp outputs an internal server error when it should throw an error message from lxc with the actual error

The first time I hit "backup ct", it creates a file in /var/lxc-backups in this format:

d2-2014-12-19__08-12.tar.gz

where d1 is the container name, 2014-12-19 is the date. The 08-12 part seems constant though, even though the time is 08:54 am now. If I have to make another backup for the same container today, the old backup gets overwritten.

Something I noticed in PyCharm and when looking at the python ldap code.

Even if I use the new example config with my own secret_key without modifying anything else, --debug mode will print:

• Missing secret_key in your config file, your session will not survive server reboot

Not sure what's meant by session not surviving a reboot so can't test if it works or not.

Currently, Flask is running in single thread, hence access from different places is not possible if there is some container operation.

Possible implementations:

1. Start Flask with "threaded=True" option
2. Dedicate extra thread to LXC API access
3. Asynchronous LXC API (if possible)

Option 1 seems to be working fine, but some testing needs to be done (especially testing If LXC api is threadsafe - for example multiple container creation at the same time).
Option 2 can be used if option 3 isn't possible (either new thread for every LXC request or one thread with thread-safe queue)

Combination of 1 and 2 seems to be efficient and safe even if LXC API cannot be accessed in threaded way (single thread-safe queue with one worker also handles concurrency -> for example deletion of container that is currently in process of creation)

To protect data, perhaps we can implement the following script to do a graceful shutdown on containers?

https://github.com/foomip/lxc-scripts/blob/master/lxc-graceful

Since the user database is put directly in the .deb package under /srv/lwp/lwp.db, reinstalling the package, or installing a new version is going to reset the user database each time.

I have this in my config file:

ssl = True
pkey = dudemon.key
cert = dudemon.cert

certs are contained in the same directory as lwp.conf.

I launch the server (both with service lwp start and by manually running python /srv/lwp/lwp.py)

And it says it's working on http rather than https.

I remember a few days ago I also received an exception which now I cant't reproduce, I'll try again and keep you updated.

This is in reference to #12, especially #12 (comment):

Here's some output with the --profiling option:

--------------------------------------------------------------------------------
PATH: '/home'
         465467 function calls (445754 primitive calls) in 89.247 seconds

   Ordered by: internal time, call count
   List reduced from 756 to 30 due to restriction <30>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      209   87.931    0.421   87.931    0.421 {method 'read' of 'file' objects}
      200    0.531    0.003    0.531    0.003 {posix.read}
      200    0.115    0.001    0.115    0.001 {posix.fork}
     8149    0.038    0.000    0.038    0.000 {posix.stat}
      200    0.035    0.000    0.698    0.003 /usr/lib/python2.7/subprocess.py:1187(_execute_child)
       53    0.035    0.001    0.075    0.001 /usr/lib/python2.7/ConfigParser.py:464(_read)
    12244    0.025    0.000    0.025    0.000 {method 'match' of '_sre.SRE_Pattern' objects}
     2497    0.024    0.000    0.029    0.000 /usr/local/lib/python2.7/dist-packages/werkzeug/urls.py:374(url_quote)
       74    0.020    0.000    0.587    0.008 /usr/local/lib/python2.7/dist-packages/lwp-0.6_-py2.7.egg/lwp/lxclite/__init__.py:93(ls)
    69535    0.016    0.000    0.018    0.000 {isinstance}
    15214    0.015    0.000    0.034    0.000 /usr/local/lib/python2.7/dist-packages/jinja2/nodes.py:164(iter_child_nodes)
    24837    0.012    0.000    0.015    0.000 /usr/local/lib/python2.7/dist-packages/jinja2/nodes.py:148(iter_fields)
       53    0.010    0.000    0.443    0.008 /usr/local/lib/python2.7/dist-packages/lwp-0.6_-py2.7.egg/lwp/__init__.py:230(get_container_settings)
       77    0.010    0.000    0.010    0.000 {posix.listdir}
     2128    0.009    0.000    0.030    0.000 /usr/local/lib/python2.7/dist-packages/jinja2/lexer.py:593(tokeniter)
      200    0.009    0.000    0.727    0.004 /usr/lib/python2.7/subprocess.py:650(__init__)
    25113    0.009    0.000    0.010    0.000 {getattr}
     8515    0.008    0.000    0.008    0.000 {method 'split' of 'str' objects}
       37    0.008    0.000   87.903    2.376 /usr/local/lib/python2.7/dist-packages/lwp-0.6_-py2.7.egg/lwp/lxclite/__init__.py:111(listx)
     4218    0.007    0.000    0.033    0.000 /usr/lib/python2.7/genericpath.py:38(isdir)
     8357    0.007    0.000    0.007    0.000 {method 'format' of 'str' objects}
      200    0.007    0.000   88.685    0.443 /usr/lib/python2.7/subprocess.py:544(check_output)
     3531    0.007    0.000    0.007    0.000 /usr/lib/python2.7/collections.py:54(__setitem__)
      552    0.007    0.000    0.032    0.000 /usr/local/lib/python2.7/dist-packages/werkzeug/urls.py:762(url_join)
     3922    0.007    0.000    0.030    0.000 /usr/lib/python2.7/genericpath.py:26(isfile)
      618    0.007    0.000    0.014    0.000 /usr/lib/python2.7/ConfigParser.py:590(get)
      200    0.006    0.000    0.006    0.000 {posix.fdopen}
     1600    0.006    0.000    0.006    0.000 {fcntl.fcntl}
      200    0.006    0.000   87.950    0.440 /usr/lib/python2.7/subprocess.py:768(communicate)
      552    0.006    0.000    0.046    0.000 /usr/local/lib/python2.7/dist-packages/werkzeug/routing.py:703(build)

I am however using the latest version from Git including e3e6ee6, 1f12382 and 00a36f3:

# md5sum /usr/local/lib/python2.7/dist-packages/lwp-0.6_-py2.7.egg/lwp/lxclite/__init__.py
d0727d87ca377ae832fa264bce90baed  /usr/local/lib/python2.7/dist-packages/lwp-0.6_-py2.7.egg/lwp/lxclite/__init__.py

# time lxc-ls --fancy | tail -n+3

(Output for 36 running and 17 stopped containers)

real    0m2.193s
user    0m0.148s
sys 0m0.116s

Hello,

it seems that a FQDN ist not allowed during container creation.

• test01.company.com doesn't work
• test01 is working well

Would be nice if we can use the FQDN as a container name since we have a lot of customers on one physical host with the same subdomain name, e.g. test01.customer1.com, test01.customer2.com and so on.

Regards,
Karsten

do you know where the logs are kept? I am getting an internal server error after logging in...

It would be nice to see on the overview whether a container is set to start on boot or not. (maybe even the boot order?)

http://192.168.1.118:5000/static/css/bootstrap.min.css is missing,

it looks like it isn't in the git repo but is linked to from the main page:

There are a few instances where it says "desciption" without an r in tokens.html.

table column header

form field placeholder

I was using the original LWP.. I removed /srv/lwp, then installed this LWP.. When trying to login I get https://gist.github.com/anonymous/d01a81bc0193afe3b064

Nothing is using this file, I searched the code and nothing is using it, can be removed.

I had some issues overinstalling 0.5 to 0.6 (from .deb) and found out that the issue turned out to be that the lwp service was not shut down properly before installing the new package and a reboot fixed it.

That appears to be fixed now, but I had a look the source and found out the init script is in debian/files and registered manually in the postinst maintainer script, when it should really be in the debian folder and end on ".init", e.g. "lwp.init" so dh_installinit will pick it up and register it automatically. See: https://www.debian.org/doc/manuals/maint-guide/dother.en.html#initd

For this to work, the postinst and other "maintainer scripts" need to have a special placeholder #DEBHELPER# in them, where dh_installinit will populate that.

Also, while on the topic of maintainer scripts, they should also really check the argument passed to them in $1, e.g. "configure" for postinst, see: https://wiki.debian.org/MaintainerScripts

I am quite good with Debian packaging, and can fix these things if you want.

Also, I was wondering why not use an upstart script instead of classic init script, or do you need this to run on Debian too?

Hi

I'm running Ubuntu 14.04 LTS.

I installed LWP, tried to login and I got an internal server error. After some searches and found several issues related to the content of /var/lib/lxc I found LWP crashes if LXC is not yet installed.

LWP should check if /var/lib/lxc exists and show a more friendly message.

After a apt-get install lxc, lwp works (at least I can login)

Error seen for PAM auth on Fedora 21 after login.

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1836, in __call__
    return self.wsgi_app(environ, start_response)
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1820, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1403, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/lib/python2.7/site-packages/lwp-git_-py2.7.egg/lwp/views/auth.py", line 88, in login
    p = pam.pam()
AttributeError: 'module' object has no attribute 'pam'

Hello!

I've just installed LWP, and so far I'm quite happy with it (was giving up on it before I found your fork).

One issue I ran into is that the "Disk usage" part is using not taking into account the location of the containers and just shows the df of /. Given that my containers are not located there, it's not helpful, but what I thought of is even in case it would use the right device, it would not be useful as it's a raid array that just happens to have the LXC folder too.

I think a better way would be to read lxc.lxcpath from the config, and do the free/used space calculation based on that.

Cheers,
Peter

Currently user auth view should be refactored so adding new ways of authentication will be easy

Following the instructions in README.rst:
wget -O - http://claudyus.github.io/LXC-Web-Panel/claudyus.gpg.key | sudo apt-key add -
echo "deb http://claudyus.github.io/LXC-Web-Panel/ debian/" | sudo tee /etc/apt/sources.list.d/lwp.list
sudo apt-get update
sudo apt-get install lwp

$ service lwp start
start: Unknown job: lwp

no lwp in /etc/init.d
I am on ubuntu 14.04.

/usr/sbin/lwp works, just not added to startup.
how to add to startup?

The lwp.py file has a SECRET_KEY stored in the code, this is a security vulnerability as all lwp installations are using the same secret key which is known.

This should be read from the config file instead, with a clear comment in the example config file that the user should put a random secret key of their own in order to properly secure their lwp installation.

On a container I cloned, I still have the lxc.network.ipv4 line configured but I turned off the network and changed the network type to empty. However, the IP address is still displayed in the summary.

It seems much more intuitive that the overview shows only the up and running ip addresses. As of now I have the same address appearing on the original and the clone container and it can be confusing.

Moreover, lxc-ls --fancy has the behavior I explain here.

Here is the problematic config :

lxc.network.type = empty
lxc.network.flags = down
lxc.network.link = eth1
lxc.network.ipv4.gateway = 192.168.93.1
lxc.network.ipv4 = 192.168.93.40