How to recognize the hardware platform you are running on.

It is sometimes required especially when managing many servers to recognize the hardware setup you are running on especially if you have a zoo of different animals. 

Great tool for getting detailed hardware report including bios versions and memory / processor info :

 

dmidecode

While the output varies slightly across distros and sometimes you need to install it e.g.

 yum -y install dmidecode

It is a great tool for understanding the underlying system and to know if you’re on a VM or not.

 

nJoy 😉

Starting vnc on Display 0 ( local display ) from a remote ssh session

i.e. You wnet home need your desktop have ssh no vnc !! Here is the easy solution..

Install x11vnc.

$ DISPLAY=localhost:0 x11vnc &

connect to the display using vnc et voila !

BTW Teamviewer also USED TO WORK but no longer in ver 8 so thanks VNC for not being obsolete..

nJoy 🙂

 

Start Teamviewer from an ssh session remotely

So you remote deskptop rebooted and teamviewer did not run on startup as it does not do in Linux for some strange reason:

Connect with ssh ( putty)

Then run

DISPLAY=`localhost`:0 teamviewer&

Njoy 🙂 !

Enable grub menu UBUNTU

Enable grub menu:

edit the /etc/default/grub  file and change the

GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true

to

GRUB_HIDDEN_TIMEOUT=10
GRUB_HIDDEN_TIMEOUT_QUIET=false

Save and call:

sudo update-grub

from a terminal, and reboot.

Manually reset the state of an instance

If an instance gets stuck in an intermediate state (e.g., “deleting”), you can manually reset the state of an instance using the nova reset-state command. This will reset it to an error state, which you can then delete. For example:

$ nova reset-state c6bbbf26-b40a-47e7-8d5c-eb17bf65c485

$ nova delete c6bbbf26-b40a-47e7-8d5c-eb17bf65c485

You can also use the --active to force the instance back into an active state instead of an error state, for example:

$ nova reset-state –active c6bbbf26-b40a-47e7-8d5c-eb17bf65c485

 

[Note] Note
The version of the nova client that ships with Essex on most distributions does not support the reset-statecommand. You can download a more recent version of the nova client from PyPI. The package name ispython-novaclient, which can be installed using a Python package tool such as pip.
Reference: Openstack Docs

LTS and Release Cycle for Ubuntu

LTS is an abbreviation for “Long Term Support”.

We produce a new Ubuntu Desktop and Ubuntu Server release every six months [diagram below]. That means you’ll always have the latest and greatest applications that the open source world has to offer. Ubuntu is designed with security in mind. You get free security updates for at least 18 months on the desktop and server.

A new LTS version is released every 2 years. In previous releases, a Long Term Support (LTS) version had 3 years support on Ubuntu (Desktop) and 5 years on Ubuntu Server. Starting with Ubuntu 12.04 LTS, both versions will receive 5 years support. There is no extra fee for the LTS version; we make our very best work available to everyone on the same free terms. Upgrades to new versions of Ubuntu are and always will be free of charge.

The LTS designation applies only to specific subsets of the Ubuntu archive. The LTS may not apply to all flavors and remixes of Ubuntu. For example, for 8.04 LTS, Kubuntu chose to move to KDE 4.0 and didn’t issue an LTS release. In 10.04, the Netbook Edition was not an LTS. The project will decide which flavors will be LTS and the support duration for each, early in the LTS development cycle.

Some of the latest support windows are illustrated below:

ubuntu-release-cycle-2.png

Release Plan Details

  1. We are more conservative in our package merge with Debian, auto-synching with Debian testing, instead of Debian unstable.
  2. We start stabilizing the release early by significantly limiting the number of new features. We will choose which features we package into the LTS release, versus which ones we leave out and allow for users to optionally download and use from a separate archive.
  3. Avoid structural changes as far as possible, such as changing the default set of applications, lots of library transitions, or system layer changes (example: introducing KMS or hal → DeviceKit would not have been appropriate changes in a LTS).

Furthermore, we define the LTS to be:

  • Enterprise Focused: We are targeting server and multiple desktop installations, where the average user is moderately risk averse.
  • Compatible with New Hardware: We will make point releases throughout the development cycle to provide functional support for new server and desktop hardware.
  • More Tested: We will shorten the development window and extend the Beta cycle to allow for more testing and bug fixing

and clearly state that it is not:

  • A Feature-Based Release: We will focus on hardening functionality of existing features, versus introducing new ones1, except for in the areas of Online Services and Desktop Experience2.
    • 1. Exceptions for priority projects will be documented.~
      ~-2. Because these two areas of development are relatively new, they still require new features to satisfy the original reasons for their creation
  • Cutting Edge: Instead of doing an automatic full package import from Debian unstable, we will do it from Debian testing1. The benefit we gain from not introducing new bugs and/or regressions outweighs the new features and/or fixes we often get from unstable.
    • 1. We reserve the right to selectively pull in updates from unstable, if we believe the stability of the package in Debian is better than what is in the current Ubuntu archive.

 

LTS Schedule

To support our goal of ensuring stability, we plan to make a small number of changes to the release schedule:

  1. Reduced Alpha Stage: Because we will have substantially less new code, we can reduce the number of Alpha releases, and extend the Beta stage to allow for more system testing.
  2. Two Beta Releases: We generally get more bugs filed in the Beta stage because of the increase in user base. In order to address more of these issues, we will provide an additional Beta release.

Quoted from here.

Openstack Compute logs location

The log files are located here :

/var/logs/nova

Logfiles are :

nova-api.log
nova-cert.log
nova-compute.log
nova-dhcpbridge.log
nova-manage.log
nova-network.log
nova-objectstore.log
nova-scheduler.log
nova-volume.log
nova-xvpvncproxy.log

 

Permanently set hostname in Ubuntu

Debian based systems use the file /etc/hostname to read the hostname of the computer at boot time and set it up using the init script /etc/init.d/hostname.sh

One can edit the file /etc/hostname and change the hostname and then run:

/etc/init.d/hostname.sh start

Update /etc/hosts ip 127.0.0.1 respectively ( leave the localhost entry untouched)

Steps:

  1. sudo vi  /etc/hostname
  2. Save the file with the hostname you like to set
  3. sudo /etc/init.d/hostname.sh start
  4. sudo vi /etc/hostname
  5. Save file with 127.0.0.1 entry updated
  6. Test using hostname -f
  7. Log off using exit

Ref: http://sysblogd.com/50/change-hostname-permanently-on-debian-or-ubuntu.htm