I haven't tried to do the upgrade with the adjustments. Can anyone confirm that
adding the permissions for the key store to the cloud user will make it
complete.
Sent on a Sprint Samsung Galaxy S® III
Original message From: Ian Duffy
Date:10/24/2014 9:06 PM (GMT-05:00)
To
> so I guess CS never updates it, and anyone who
installed a version with a sudo config missing keytool will probably hit
this same problem eventually
Correct. The modification of the sudoers file isn't done via the binary
package so it will not change on update.
It will only change if cloudstack-
Right, it is not ideal, though it was like that for a long time (since
at least CS 2.x). I see that the sudo config was changed recently to be
more locked down, but it did not include keytool due to CLOUDSTACK-1389.
I checked a 4.3 setup which was upgraded from 4.2 and it still has the
old unrest
> cloud ALL =NOPASSWD : ALL
This is dangerous advice. It grants the cloud user full sudo access without
the requirement of a password.
The following gives more limited access and should allow cloudstack to
function accordingly:
cloud ALL =NOPASSWD : /bin/chmod, /bin/cp, /bin/mkdir, /bin/mount,
/
Just did quick management server ACS 4.4.1 installation on free server:
cloud ALL =NOPASSWD : /bin/chmod, /bin/cp, /bin/mkdir, /bin/mount,
/bin/umount, /usr/bin/keytool
that is what it looks like in ACS 4.4.1
clean install of ACS 4.4.1 works...
On 24 October 2014 19:35, Andrija Panic wrote:
> l
like this:
Defaults:cloud !requiretty
cloud ALL =NOPASSWD : ALL
and let us know if the upgtade still fails - it does fail for me with no
understandable error...
thx
On 24 October 2014 19:28, Matthew Midgett <
clouds...@trick-solutions.com.invalid> wrote:
> This is what is in my sudoers file
>
>
This is what is in my sudoers file
cloud ALL =NOPASSWD : /bin/chmod, /bin/cp, /bin/mkdir, /bin/mount, /bin/umount
Should I change it?
-Original Message-
From: Kirk Kosinski [mailto:kirkkosin...@gmail.com]
Sent: Friday, October 24, 2014 5:23 AM
To: users@cloudstack.apache.org
Subject: R
My internal DNS is working (I installed dnsmasq on the management server
and set it to listen on the internal IP address 10.1.40.3). From the hosts
and guests, pinging the management server by name goes to the correct
internal address. Where do the arguements in /var/cache/cloud/cmdline come
from
and internal DNS - it must be accessible/routable from mgmt network - when
I set internal dns to be 8.8.8.8 then SSVM check was failing, and I had bad
routes as you do at the moment...
So no routes for internal DNS should be added at all in my opinion, it's is
on the administarator of the CS to all
I had the same/similar issues, when my mgmt server and agents (bridge on
them) had public IP...I add host as 10.x,x,x to the cloudstack, and the
cs-agent reads the public IP address from the bridge and defines that
public IP as the host IP inside cloudstack (acs 4.4)
On 24 October 2014 01:06, John
Hi guys,
trying vxlan as isolation method, and although manual testing of vxlan
works fine (so kernel and IP binary are fine) - I'm dont have inter-host
communication at all...
Per documentation, I should have created a bridge (cloudbr3 in my example,
IP address is set on the bridge). trafic labe
Hi, the error below indicates a problem with the sudo config. Make sure
/etc/sudoers has a line like:
cloud ALL =NOPASSWD : ALL
Best regards,
Kirk
On 10/23/2014 01:05 PM, Matthew Midgett wrote:
> 2014-10-23 15:21:52,943 INFO [c.c.s.ConfigurationServerImpl] (main:null)
> Processing updateSSLKe
12 matches
Mail list logo
