Imaging Backend not working in eucalyptus - eucalyptus

I have installed eucalyptus 4.4.4 on Centos 7 and I have already done all installation steps but it is still showing "imagingbackend" as not ready.

The imaging service is not always required when using eucalyptus. Particularly for smaller deployments it can be a good choice to skip configuration of the imaging service and save the resources (virtual machine instances) that would have been used by the imaging service for user workloads.
To enable the imaging service you need to install and register the service image (v5 output shown):
# esi-describe-images
SERVICE VERSION ACTIVE IMAGE INSTANCES
imaging 5.0.100 * emi-b54e3b35170d2c56e 1
loadbalancing 5.0.100 * emi-b54e3b35170d2c56e 0
and create the stack:
# esi-manage-stack -a check
Stack 'euca-internal-imaging-service' currently is in CREATE_COMPLETE state.
the steps to get to this state are covered in the documentation:
http://docs.eucalyptus.cloud/eucalyptus/4.4.5/index.html#install-guide/configure_imaging_service.html
You can also use esi-manage-stack to delete / create the imaging stack:
# esi-manage-stack -a delete
services.imaging.worker.configured = false
# esi-manage-stack -a create
Stack 'euca-internal-imaging-service' currently is in DELETE_IN_PROGRESS state. Please wait till the end of previous stack change operation.
# esi-manage-stack -a create
services.imaging.worker.configured = true
#
If you have gone through these steps but the service is not enabled you should do basic checks to verify that you can run any instances in your cloud:
# euca-describe-instance-types --show-capacity
# euserv-describe-events
and also check the log for errors /var/log/eucalyptus/cloud-debug.log

Related

Failed to install JUPYTER in restricted dataproc setup

I am looking to setup a dataproc cluster with Jupter optional component .
gcloud beta dataproc clusters create cluster-1ea3 --enable-component-gateway \
--region europe-west1 --subnet data-network --no-address --zone europe-west1-b \
--single-node --master-machine-type n1-standard-4 --master-boot-disk-size 500 \
--image-version 1.5-debian10 --optional-components ANACONDA,JUPYTER \
--scopes 'https://www.googleapis.com/auth/cloud-platform' --project clouddemoenvironment
"--no-address" ensures private IP and the network "data-network" is enabled with Google private access. Things works great if i am not installing Jupyter optional component but cluster fails to come up with below error with optional components.
<13>Nov 5 09:01:44 google-dataproc-startup[1466]: <13>Nov 5 09:01:44 activate-component-jupyter[2710]: Looking in links: /opt/dataproc/jupyter/gcp
<13>Nov 5 09:01:44 google-dataproc-startup[1466]: <13>Nov 5 09:01:44 activate-component-jupyter[2710]: Collecting https://github.com/GoogleCloudPlatform/jupyter-extensions/archive/2cb9d24fe01cd329a8c4352a07b0eb8f9771fb07.zip#subdirectory=jupyter-gcs-contents-manager (from -r /opt/dataproc/jupyter/jupyter_extra_packages.requirements (line 1))
<13>Nov 5 09:01:59 google-dataproc-startup[1466]: <13>Nov 5 09:01:59 activate-component-jupyter[2710]: WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<pip._vendor.urllib3.connection.VerifiedHTTPSConnection object at 0x7f6b1afbac10>, 'Connection to github.com timed out. (connect timeout=15)')': /GoogleCloudPlatform/jupyter-extensions/archive/2cb9d24fe01cd329a8c4352a07b0eb8f9771fb07.zip
I understand that the cluster has no access to github and it makes sense to fail. On checking the documentation it was quoted
If you create a Dataproc cluster with internal IP addresses only, attempts to access github.com over the Internet in an initialization action will fail unless you have configured routes to direct the traffic through Cloud NAT or a Cloud VPN. Without access to the Internet, you can enable Private Google Access, and place job dependencies in Cloud Storage; cluster nodes can download the dependencies from Cloud Storage from internal IPs.
I don't want to use Cloud NAT or Cloud VPN . Is there some thing i can convey to the system to resolve the dependency in a different way . Unfortunately the initialization script concept might also wont work as the order of execution comes after the Optional components.
Any suggestions how I can leverage Optional Components in a non internet environment.
Regards,
Jill
This startup time dependency is a bug in the latest Dataproc images.
It should be fixed with the next Dataproc subminor image version release.
To work around this for now, you can use the previous subminor image version. (--image-version=1.5.18-debian10)
UPDATE: this problem has been fixed in the Nov 9 2020 release, so you can just use the latest version.

EUCA 4.4.5 VPCMIDO Instances Terminate at Launch

I have achieved a small test cloud on 3 pieces of hardware. It works fine when in EDGE mode but when I try to configure it for VPCMIDO, new instances begin to launch but then timeout and move to a terminated state. I can also see the instances' initial volume and config data appear in the NC and CC data directories. Below is my system layout and network.json.
HOST 1 : CLC/UFS/WALRUS/MIDO CLUSTER/MIDO GATEWAY/MIDOLMAN AGENT:
em1 (All Services including Mido Cluster): 10.0.0.21
em3 (Target VPCMIDO Adapter): 10.0.0.22
HOST 2 : CC/SC
em1 : 10.0.0.23
HOST 3 : NC/MIDOLMAN AGENT
em1 : 10.0.0.24
{
"Mido": {
"Gateways": [
{
"Ip": "10.0.0.22",
"ExternalDevice": "em3",
"ExternalCidr": "192.168.0.0/16",
"ExternalIp": "192.168.0.2",
"ExternalRouterIp": "192.168.0.1"
}
]
},
"Mode": "VPCMIDO",
"PublicIps": [
"10.0.100.1-10.0.100.254"
]
}
I may be misunderstanding the intent of reserving an interface just for the mido gateway. All of my eucalyptus/zookeeper/cassandra/midonet configs use the 10.0.0.21 interface and seem to communicate fine. The midonet tunnel zone reports my CLC host and NC host successfully in the tunnel zone. The only part of my config that references the interface I intend to use for the midonet gateway is the network.json. No errors were returned at any time during my config so I think I may be missing something conceptual.
You may need to start eucanetd as described here:
https://docs.eucalyptus.cloud/eucalyptus/4.4.5/index.html#install-guide/starting_euca_clc.html
The eucanetd component in vpcmido mode runs on the cloud controller and is responsible for controlling midonet.
When eucanetd is not running instances will fail to start as the required network resources will not be created.
I configured a bridge on the NC and instances were able to launch and I no longer got an error in my nc.log. Docs and the eucalyptus.conf file comments tell me I shouldn't need to do this in VPCMIDO netowrking mode: https://docs.eucalyptus.cloud/eucalyptus/4.4.5/index.html#install-guide/configuring_bridge.html
Despite all that adding the bridge fixed this issue.

Camera (/dev/video0) dependencies in systemd service Ubuntu 16.04

I need to run some services on boot up which I have successfully accomplished using systemd services. (Lots of answers already available).
Now, one of my service requires access to /dev/video0 while bootup when a certain user is logged in. (I am doing auto login which is working fine).
So how do I check that whether the /dev/video0 is available before starting my systemd service while bootup.
I came across something called udev for doing this, I followed this link
but I am not getting desired output as after editing /lib/udev/rules.d/99-systemd.rules files as mentioned in the link and starting my service manually it's not starting, any help is appreciated.
Finally after struggling for a day I found the answer -
I made a script in /etc/systemd/system which contains
[Unit]
Description='some description of my file write according to you'
[Service]
Type=forking
ExecStart='path to script'
[Install]
WantedBy=multi-user.target
and It executes a script which contains
#!/bin/bash
modprobe uvcvideo
Now after rebooting all the services are running properly
mod probe uvcvideo command check for running video driver and enable it at the time of bootup so that It is available for my systemd process
Thanks

HAAst terminating with exit code 158

I'm just trying to do a POC test with Telium's HAAst before we offer it to a customer, but I've stalled before I start the haast daemon. Currently I have a single VM with Ubuntu 16.04 LTS with Digium's basic Asterisk 13 installation. I've configured haast.conf, it seems good, but I cannot start haast daemon, it stops after a few seconds. Here is the relevant log output:
General, HAAst version 2.3.2.1 starting as daemon under process ID 2409
Controller, Local peer HAAst state changing to service start
License, License file not found. Switching to Free Edition
General, Settings contained 0 information; 0 warning; and 0 error messages.
Asterisk Controller, Unable to located executable to control Asterisk
Controller, Local peer HAAst state changing to service stop
Controller, Stopped
General, HAAst terminating with exit code 158 (failure to find asterisk control files) after running for 2 seconds
It seems, haast misses the event controller to start Asterisk daemon, unfortunately it didn't contain the installation package. I've tried to make these files (asterisk.start & asterisk.stop) based on the other sample event files, I've set the executable bit, I've wrote the shebang to the first line based on the installation guide, but nothing helped.
Is somebody experienced about this case?
Thanks, Zsolt
This error means that High Availability for Asterisk (HAAst) is unable to find the service/executable file needed to control Asterisk. Since the 'distribution' setting in the [asterisk] stanza of the haast.conf file is it to 2 (Digium Asterisk), it means there's a problem with the Asterisk service file.
Ubuntu 16 uses systemd so have you installed Digium's asterisk.service (systemd) file? If you chose to install an initd service file for Asterisk instead then you may have to explicitly tell HAAst which to look for. If you installed neither then that's your problem. The maker of HAAst (Telium) has a support forum where this topic is addressed (click here).
The pre and post Asterisk event handlers are available in the commercial versions of HAAst only - so that won't help (but it's also the wrong way to solve the problem). There are also a few Ubuntu specific topics on the support forum https://www.telium.io/haast in case that helps.
If you can't find an Asterisk systemd service file here's a sample:
[Unit]
Description=Asterisk PBX and telephony daemon
Documentation=man:asterisk(8)
Wants=network.target
After=network.target
[Service]
Type=simple
User=asterisk
Group=asterisk
ExecStart=/usr/bin/asterisk -f -C /etc/asterisk/asterisk.conf
ExecStop=/usr/bin/asterisk -rx 'core stop now'
ExecReload=/usr/bin/asterisk -rx 'core reload'
[Install]
WantedBy=multi-user.target
Just save that file as 'asterisk.service' and place in /etc/systemd/system/ and ensure permissions match other service/unit files.
Haast configuration is missing or not correct:
Unable to located executable to control Asterisk

Installing Java/Tomcat via SaltStack using non-root user on Ubuntu

I am able to do following
install salt master, minion (using root user)
login in master machine and execute salt command to install java / tomcat into minion server
result : java/tomcat is installed via root user
What i want to do is
install java / tomcat in minion server by user name 'tomcatuser'
As per my understanding only way of doing this is if i install my minion via tomcatuser.
Is my understanding correct ?
Any other way ?
I think you mix up the saltstack controller and how it control the application configuration.
For salt master and minion to communicate, you need to start both services as root, to control most of the configuration process. Then from there on, you can specify the user and group for application deployment inside your sls configuration.
Now come to your Tomcat/java/whatever package, you can refer to the salt stack configuration, to specify your own user group of the configuration and even startup(with other modification). e.g.
Deploy foo configuration:
file.managed:
- name: /etc/foo.conf
- source:
- salt://foo.conf
- user: foo
- group: users
- mode: 644
Then to startup your tomcat, you can do the similar by using a crontab and specify the user you want (as long as it is not load under service port smaller than 1024) . Or you can check whether salt.states.tomcat is helpful to start the services : https://docs.saltstack.com/en/latest/ref/states/all/salt.states.tomcat.html

Resources