I downloaded a qcow2 image from Atomic official site, but I really frustrated with the steps to start this qcow2 image, and no helpful clear tips from Google.
Anyone can give me some clear hints on how to start the qcow2 vm? Thanks.
The image name is: Fedora-Atomic-25-20170131.0.x86_64.qcow2
The Fedora Atomic Host (FAH) qcow is a cloud image, so it expects a Metadata source. Metadata is all the configuration bits a generic cloud image uses to get configured. Specifically, it requires something that the cloud-init package recognizes. You can read more about cloud-init here. If you just want to fire off some one-off VMs for testing, a tool you can use is testcloud.
Using testcloud to launch the VM, you'll be able to log in with the user 'fedora' (which is the default in Fedora based cloud images) and the password 'passw0rd' (you can change this default in the config).
The other option is to download the installer ISO, and then you can install into a fresh VM and not have to worry about metadata at all. You can find that here, under "Other Downloads" on the right hand side.
The #fedora-cloud channel on Freenode is a good place to check if you have any other questions.
Related
I'm running jira in openshift using the basic image from atlassian: https://hub.docker.com/r/atlassian/jira-software
So far most things work fine.
I installed a plugin using the web ui which worked as well.
But now I'm running into an issue when a pod is restarted. The pod uses the image and naturally (as specified) my plugin is not installed anymore. I can install the plugin via webservice calls and register it as an osgi module for jira. But I don't want to do this manually. Building a pipeline or jon for this is quite easy (I'm thinking jenkins or ansible tower). But I so far I didn't find a way to trigger this pipeline after the pod is started (or better after jira is started).
Anyone got an idea how to handle this?
Thanks and best regards. Sebastian
Why not create a custom image based on the Atlassian image with everything you need installed?
As far as I know, there isn't a way to trigger a pipeline when a Pod is started; only Webhook, Image Change, and Config Change triggers are available. You'll need to write a Jenkinsfile to script all of the installation and setup you want, but then that can be triggered in one of the three ways mentioned.
I'm thinking an Image Change trigger would work best for you, so when the latest version of Atlassian's image comes out, you can run your pipeline to set everything up on the latest version.
Also, just curious, but do you have some persistent storage attached to the Jira pod? If not, you'll lose everything in Jira if the Pod dies; that means tickets, boards, comments, everything.
Update:
Looking at this page, it looks like most of the stuff you're trying to persist is stored in jira-home, so maybe mounting that as a persistent volume will be a good solution for you.
You're correct that the tickets are stored in the database, but I'm guessing the database connection settings are getting wiped when the Pod is cycled.
The jira-home directory stores your application and database connection settings, as well as a subdirectory for your plugins.
dbconfig.xml
This file (located at the root of your JIRA home directory) defines
all details for JIRA's database connection. This file is typically
created by running the JIRA setup wizard on new installations of JIRA
or by configuring a database connection using the JIRA configuration
tool.
You can also create your own dbconfig.xml file. This is useful if you
need to specify additional parameters for your specific database
configuration, which are not generated by the setup wizard or JIRA
configuration tool. For more information, refer to the 'manual'
connection instructions of the appropriate database configuration
guide in Connecting JIRA to a database.
jira-config.properties
This file (also located at the root of your JIRA home directory)
stores custom values for most of JIRA's advanced configuration
settings. Properties defined in this file override the default values
defined in the jpm.xml file (located in your JIRA application
installation directory). See Advanced JIRA configuration for more
information.
In new JIRA installations, this file may not initially exist and if
so, will need to be created manually. See Making changes to the
jira-config.properties file for more information. This file is
typically present in JIRA installations upgraded from version 4.3 or
earlier, whose advanced configuration options had been customized
(from their default values).
plugins/
This is the directory where plugins built on Atlassian's Plugin
Framework 2 (i.e. 'Plugins 2' plugins) are stored. If you are
installing a new 'Plugins 2' plugin, you will need to deploy it into
this directory under the installed-plugins sub-directory.
'Plugins 1' plugins should be stored in the JIRA application
installation directory.
This directory is created on JIRA startup, if it does not exist
already.
I have an old Debian Compute Engine instance (created and running since December 2013) and got an email warning about the turndown of Legacy GCE and GKE metadata server endpoints (more details at https://cloud.google.com/compute/docs/migrating-to-v1-metadata-server).
I followed the directions for locating the process and found that the requests were coming from /usr/share/google/google_daemon/manage_addresses.py. The script seems to be the same as what's at https://github.com/gtt116/gce/blob/master/google_daemon/manage_addresses.py (also with what's in that directory).
I don't recall installing this, so I'm imaging it came with the provided Debian image I used in 2013.
Does anyone know what this manage_addresses.py script is, what it does, and what I should do with it now that the legacy metadata server endpoints are turning down? Is it safe to just stop running it? Or is there a new script I should replace it with? Or should I just try to update it myself to use the new endpoint?
I dug around and was able to trace /usr/share/google/google_daemon/manage_addresses.py as being installed by a package called google-compute-daemon. A search for that brought me to https://github.com/GoogleCloudPlatform/compute-image-packages#troubleshooting which explains that google-compute-daemon has been replaced with python-google-compute-engine. That led me to https://cloud.google.com/compute/docs/images/install-guest-environment . I followed the instructions there and manually installed the guest environment.
I noticed during installation that it said it was removing the google-compute-daemon package (and a packaged called google-startup-scripts), so this seems like the right thing. And I'm no longer seeing any requests to the legacy endpoints. So it seems like at some point the old guest environment failed to update.
TLDR; If you have this problem, follow the instructions at https://cloud.google.com/compute/docs/images/install-guest-environment#installing_guest_environment to manually update the guest environment.
I'm using qemu to replace bochs (since it doesn't update anymore)
In bochs, I can save the running settings into files and reload it. Furthermore, there will be a listed table of running options while boot up.
I'm wondering if I can do the same with qemu, save running settings such as cpu model, and other stuffs into some files and reload it next time I run emulation.
And if there exists a full listed running option table like thing for me to have a complete view on which options I can set.
Thanks a lot!
For this sort of UI and management of VMs you should look at a "management layer" program that sits on top of QEMU. libvirt's "virt-manager" is one common choice here. A management-layer will generally allow you to define options for a VM and save them so you can start and stop that VM without having to specify all the command line options every time. It will also configure QEMU in a more secure and performant way than you get by default, which often requires rather long QEMU command lines.
QEMU itself doesn't provide this kind of facility because its philosophy is to just be the low-level tool which runs a VM, and leave the UI and persistent-VM-management to other software which can do a better job of it.
Is there a possibility to enable 2 factor authentication (or 2 step verification a-la Google terminology) for Google compute engine?
I'm interested in protecting my VMs, cloud storage and the developers console.
I've tried using the Google Authenticator (libapm) referring to this article Securing SSH with two factor authentication using Google Authenticator on a VM but it didn't succeed (I managed to login with the gcloud compute shell with no additional code).
[Jan 12th]
Some updates:
Google developer console works perfectly. Thanks.
For 2-step verification with the compute-engine SSH access, I retried everything all over again. Followed the instructions mentioned in the links provided, and did the following:
I created a new Google-Cloud project.
I used 2 different OS instances - Debian 8.2 and Ubuntu 15.10.
All of these tests failed - there was no prompt for a verification code.
I looked around in the Google compute-engine documentation, and they mention explicitly they support only certificate authentication (rather than username/password), so I cannot verify whether this is the root cause.
Is there anyone using 2-step verification with Google compute-engine?
Thanks
At last - a solution (thanks for Google cloud support).
A couple of updates on top of the document I have referred to:
Apart of adding a line to /etc/pam.d/sshd, one should also comment out the #include common-auth line. So it should be something like:
auth required pam_google_authenticator.so # from the original instructions
# #include common-auth # commenting out is new...
Apart of changing the ChallengeResponseAuthentication property in /etc/ssh/sshd_config, one should also add AuthenticationMethods publickey,keyboard-interactive in the following line:
ChallengeResponseAuthentication yes # from the original instructions
AuthenticationMethods publickey,keyboard-interactive # this is new...
Of course, this is on top of the regular instructions of installing libpam-google-authenticator, changing the sshd and sshd_config (as mentioned above), restarting the ssh/sshd service, and setting up the google-authenticator for the account.
Finally, a few more points:
Consider this carefully - from restarting the ssh/sshd account, no one can login without proper 2FA. So make sure anyone who should have ssh access - configured it properly.
I'm contemplating whether this is the proper solution for us, as it requires setup the VMs (each VM separately), and manual setting up the authenticator per each account and each VM manually. Not sure how scalable is this alternative. I would appreciate your thoughts...
Last but not least - the setup of libpam-google-authenticator may be simplified by using apt-get, no need for manually installing all dependencies and building it. Worked for me by running:
sudo apt-get install libpam-google-authenticator
Good Luck!
I want to know if it's possible and I'm looking for tutorials to set it up.
APE website says that knowledge of JavaScript programming is sufficent to follow the tutorial however I haven't been able to puzzle even the first 2 lines of the tutorial.
I'm using Ubuntu. After downloading APE I have no idea what to do. I already set up SSH to access the server.
What should be my following steps or where can I find an easier to tutorial to use comet be it through APE or something else?
Assuming your GoDaddy server is running some flavor of Linux, I don't see any reason it would not be possible. I was just looking over the documentation and I am not clear on what part you are having trouble with. What Linux distribution are you using? Do you have SSH access?
If you have ssh access and a root account you should be able to just follow the instructions to get APE running on the default port.
If you are running a Debian dist (Ubuntu and others) it looks like you should download the source from Git and compile it. There are instructions for the compilation there. You can learn about what you need to do wth Git by search for "clone git".
If you can be more specific about what you are having trouble with, we can probably be more helpful. But ultimately you should be able to install this on any dedicated server without issue.