[PATCH] Add %Used in header in Storage tab
by Socorro Stoppler
From: Socorro Stoppler <socorrob(a)us.ibm.com>
Socorro Stoppler (1):
Add %Used in the header for storage
ui/css/theme-default/storage.css | 5 +++++
ui/pages/tabs/storage.html.tmpl | 5 ++++-
2 files changed, 9 insertions(+), 1 deletion(-)
--
1.9.1
9 years
[PATCH] Create empty files on rpm build
by Ramon Medeiros
Issue #496 - System leftovers after uninstalling Kimchi
A rpm does not remove files that are not created by the installation.
So, all the files were provided by the package and now they can be
uninstalled. Beyond this, the function that creates the proxy conf now
accepts empty files to fill the configuration.
Signed-off-by: Ramon Medeiros <ramonn(a)linux.vnet.ibm.com>
---
contrib/kimchi.spec.fedora.in | 9 +++++++++
src/kimchi/proxy.py | 4 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/contrib/kimchi.spec.fedora.in b/contrib/kimchi.spec.fedora.in
index 9f7bb59..d06c771 100644
--- a/contrib/kimchi.spec.fedora.in
+++ b/contrib/kimchi.spec.fedora.in
@@ -92,6 +92,12 @@ mkdir -p %{buildroot}/%{_localstatedir}/log/kimchi/
touch %{buildroot}/%{_localstatedir}/log/kimchi/kimchi-access.log
touch %{buildroot}/%{_localstatedir}/log/kimchi/kimchi-error.log
+# create /etc/kimchi structure
+mkdir -p %{buildroot}/%{_sysconfdir}/kimchi/
+touch %{buildroot}/%{_sysconfdir}/kimchi/kimchi-cert.pem
+touch %{buildroot}/%{_sysconfdir}/kimchi/kimchi-key.pem
+touch %{buildroot}/%{_sysconfdir}/kimchi/nginx_kimchi.conf
+
# Install the systemd scripts
install -Dm 0644 contrib/kimchid.service.fedora %{buildroot}%{_unitdir}/kimchid.service
install -Dm 0640 src/firewalld.xml %{buildroot}%{_prefix}/lib/firewalld/services/kimchid.xml
@@ -161,6 +167,9 @@ rm -rf $RPM_BUILD_ROOT
%{_sysconfdir}/kimchi/distros.d/opensuse.json
%{_sysconfdir}/kimchi/distros.d/ubuntu.json
%{_sysconfdir}/kimchi/distros.d/gentoo.json
+%{_sysconfdir}/kimchi/kimchi-cert.pem
+%{_sysconfdir}/kimchi/kimchi-key.pem
+%{_sysconfdir}/kimchi/nginx_kimchi.conf
%{_sysconfdir}/kimchi/
%{_sharedstatedir}/kimchi/debugreports/
%{_sharedstatedir}/kimchi/screenshots/
diff --git a/src/kimchi/proxy.py b/src/kimchi/proxy.py
index fafa5bc..ecf351c 100644
--- a/src/kimchi/proxy.py
+++ b/src/kimchi/proxy.py
@@ -60,8 +60,10 @@ def _create_proxy_config(options):
if not cert or not key:
cert = '%s/kimchi-cert.pem' % config_dir
key = '%s/kimchi-key.pem' % config_dir
+
# create cert files if they don't exist
- if not os.path.exists(cert) or not os.path.exists(key):
+ if not (os.path.exists(cert) and len(open(cert).read()) > 0) or \
+ not (os.path.exists(key) and len(open(key).read()) > 0):
ssl_gen = sslcert.SSLCert()
with open(cert, "w") as f:
f.write(ssl_gen.cert_pem())
--
1.8.3.1
9 years
[PATCH] Security: Prevent Bar Mitzvah attacks by disabling RC4
by Aline Manera
For reference:
- http://www.theregister.co.uk/2015/03/27/bar_mitzvah_crypto_attack/
Apparently, Kimchi does not support RC4.
$ curl -u <user:password> -H "Content-Type: application/json" -H
"Accept: application/json" https://localhost:8001/host --ciphers RC4
--tlsv1.1
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure
But as we've already started some discussion to replace nginx to other
reverse proxy, I prefer to have this configuration explicitily done to
make us aware about that issue in future.
Signed-off-by: Aline Manera <alinefm(a)linux.vnet.ibm.com>
---
src/nginx.conf.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/nginx.conf.in b/src/nginx.conf.in
index ed926a3..e308152 100644
--- a/src/nginx.conf.in
+++ b/src/nginx.conf.in
@@ -53,6 +53,7 @@ http {
ssl_certificate ${cert_pem};
ssl_certificate_key ${cert_key};
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
+ ssl_ciphers ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
add_header X-Frame-Options DENY;
--
2.1.0
9 years
[kimchi-devel][RFC][PATCH] Storagepool on existent VG: Update document
by lvroyce＠linux.vnet.ibm.com
From: Royce Lv <lvroyce(a)linux.vnet.ibm.com>
Add interfaces to report existent volume group on host.
the returning detail will include what pool this volume group
belongs to. If this VG is not used by any storage pool, its storage_pool
will be empty string.
So the process of creating pool on existent VG will be:
1. List VG not occupied by storage pool:
GET /host/vgs?storage_pool=''
This will retrieve volume group path and user can choose from one.
2. Create storage pool from chosen VG:
POST /storagepools/
{'path':volume_group_path, 'name': storagepool_name,
'type': 'logical', 'devices':[]}
Signed-off-by: Royce Lv <lvroyce(a)linux.vnet.ibm.com>
---
docs/API.md | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/docs/API.md b/docs/API.md
index 3f7925f..ed53d94 100644
--- a/docs/API.md
+++ b/docs/API.md
@@ -986,6 +986,26 @@ stats history
* mountpoint: If the partition is mounted, represents the mountpoint.
Otherwise blank.
+### Collection: Volume groups
+
+**URI:** /host/vgs
+
+**Methods:**
+
+* **GET**: Retrieves list of volume groups.
+
+### Resource: Volume group
+
+**URI:** /host/vgs/*:name*
+
+**Methods:**
+
+* **GET**: Retrieve information of a single volume group.
+ * storage_pool: logical storage pool name which based on this volume group.
+ * path: path of this storage volume group.
+ * size: Total size of volume group.
+ * name: Name of the volume group.
+
### Collection: Devices
**URI:** /host/devices
--
2.1.0
9 years
[RFC] Do not block operations due to ref_cnt
by Crístian Viana
Hi,
I'd like to propose a change to how Kimchi uses the resource field
"ref_cnt".
Currently, "ref_cnt" - which stands for "reference count" - is one of
the fields returned when looking up a storage volume. Its purpose is to
indicate how many times that resource is being used at the moment. For
example, if the resource /storagepools/pool/storagevolumes/vol has
ref_cnt=1, it means that the disk is attached to 1 VM right now and thus
it cannot be attached to another VM. I believe the original idea of this
feature is to prevent the same resource from being attached more than
once at the same time. However, IMO, that might not always be the
desired behavior and there's no way to enforce it completely as those
resources can be used outside of Kimchi, where "ref_cnt" doesn't exist.
For example, if I have one VM which uses the disk "vol", I'm not able to
attach it to another VM via Kimchi; but if I use another libvirt-based
VM manager (e.g. virsh), I am able to attach that disk to a different
VM. This becomes even trickier when we consider other operations, like
snapshots, which can attach/detach disks while they're being reverted
to. Also, suppose I might want to inspect one VM's disk from another VM,
and then I'd need to attach one disk twice; Kimchi wouldn't allow that
by stating that the disk is already in use.
I propose Kimchi should stop using "ref_cnt" as a blocking method. The
field may still exist for information/warning messages (e.g. "are you
sure you want to attach this disk? it's already being used by another
VM.") but no operation should be blocked because of it, as it is the
case now. As inconsistencies with that value may happen and we have no
way to make sure it will always work, we shouldn't annoy the user by
stopping them from doing something that may be perfectly valid.
Any feedback will be very welcome.
Best regards,
Crístian.
9 years
[kimchi-devel][PATCHv3 0/6] Upload storage volume
by lvroyce＠linux.vnet.ibm.com
From: Royce Lv <lvroyce(a)linux.vnet.ibm.com>
known issue:
When using api to send requests without setting up session,
cherrypy server will report error after hundred of calls,
because race condition below:
https://bitbucket.org/cherrypy/cherrypy/pull-request/50/fix-race-conditio...
But it works well with session setup.
v3>v1,
Use libvirt upload api instead of r/w file
Use lock to synchronize upload to prevent
Royce Lv (6):
Update docs and json schema of storage volume upload
Update controller to make update accept formdata params
Add lock facility for storage volume upload
Update model for storage volume update
Fix incomplete record when uploading
update test case for storage volume upload
docs/API.md | 7 ++--
src/kimchi/API.json | 19 +++++++++++
src/kimchi/control/base.py | 6 ++--
src/kimchi/i18n.py | 4 +++
src/kimchi/isoinfo.py | 5 ++-
src/kimchi/mockmodel.py | 8 ++---
src/kimchi/model/storagevolumes.py | 61 +++++++++++++++-------------------
src/kimchi/model/utils.py | 46 ++++++++++++++++++++++++++
tests/test_model.py | 67 ++++++++++++++++++++++++++++++++++++++
9 files changed, 177 insertions(+), 46 deletions(-)
--
2.1.0
9 years
[PATCH] RFC patch to make nginx proxy optional
by Julien Goodwin
Sending this as an RFC patch, I expect people will want changes from this.
Implements Issue #570.
Julien Goodwin (1):
Initial prototype, make nginx proxy optional.
docs/Makefile.am | 1 +
docs/apache.conf.ex | 35 +++++++++++++++++++++++++++++++++++
src/kimchi.conf.in | 3 +++
src/kimchi/config.py.in | 1 +
src/kimchi/proxy.py | 6 ++++++
5 files changed, 46 insertions(+)
create mode 100644 docs/apache.conf.ex
--
2.1.4
9 years
[RFC] removing hostname to IP resolve in remote ISO
by Daniel Henrique Barboza
Hi there,
As discussed in our latest scrum meeting and in github bug #436, the use
of the IP address
instead of the hostname in the URLs are causing issues. This is a
workaround due to a limitation
of older qemu-io versions that don't resolve hostnames and hangs.
The thing is that we have no control of how the remote server will
resolve the URL in that format
( http://91.189.92.163:80/14.04/ubuntu-14.04.2-desktop-amd64.iso instead
of http://releases.ubuntu.com/14.04/ubuntu-14.04.2-desktop-amd64.iso for
example). It can resolve the IP to hostname and work as intended, it can
redirect to the home page (as the example I gave), it can give a 403
forbidden and so on.
This limitation is not present in newer versions of qemu (tested in RHEL
7.1, Fedora 21, Ubuntu
14.04 and Opensuse 13.2), therefore it is just a code that have a random
chance of failing to work.
In my opinion, we should get rid of it and let qemu-io handle it alone.
If qemu-io can't handle the remote
ISO streaming by itself, the user can:
- update qemu
- use an older version of kimchi
- download the ISO and use it as Local ISO Image
Thoughts?
Daniel
9 years
[RFC] New API to create a random guest console password
by Aline Manera
Today user may set/change the guest console password and also its
expiration time through Kimchi API.
When passing an empty password, a random password is automatically
generated.
curl -u <user:password> -H "Content-Type: application/json" -H "Accept:
application/json"
http://localhost:8010/vms/blah -X PUT -d'{"graphics": {"passwd": ""}}'
That way is difficult to handle when user wants to reset the guest password.
We have a similar issue when we automatically change the passwdValidTo
when it is expired - increasing it in 30 seconds.
My proposal is simple: only change "passwd" and "passwdValidTo" when
user wants to do it.
curl -u <user:password> -H "Content-Type: application/json" -H "Accept:
application/json"
http://localhost:8010/vms/blah -X PUT -d'{"graphics": {"passwd":
"123456", "passwdValidTo": "<some datetime format>"}}'
curl -u <user:password> -H "Content-Type: application/json" -H "Accept:
application/json"
http://localhost:8010/vms/blah -X PUT -d'{"graphics":
{"passwdValidTo": "<some datetime format>"}}'
And make sure the passwdValidTo is only acceptable when there is a
passwd set.
And to reset those values, we only need to send an empty string:
curl -u <user:password> -H "Content-Type: application/json" -H "Accept:
application/json"
http://localhost:8010/vms/blah -X PUT -d'{"graphics": {"password":
"", "passwdValidTo": ""}}'
And create a new API: POST /vms/blah/ticket to automatically generate a
random password valid only for 30 seconds.
curl -u <user:password> -H "Content-Type: application/json" -H "Accept:
application/json"
http://localhost:8010/vms/blah/ticket -X POST -d'{}'
What do you think about it?
Regards,
Aline Manera
9 years
[RFC] Make defaults template configurable
by Aline Manera
Hi guys,
Today when creating a Template all the default values come from Kimchi.
But in some cases, the user may want to change and persist them for next
interactions.
For example: change the disk size to 20G (instead of the default 10G),
change disk format, use Spice (instead of VNC), change storage pool and
network, etc.
My proposal is to have a configuration file
(/etc/kimchi/template.defaults) that will override Kimchi defaults
values so user can have some control on Template configuration according
to him/her proposals.
Let me know what you think about it.
Regards,
Aline Manera
9 years
