React Native Publishing an Android App

Fix package com.android.annotations does not exist

Here is how to automatically fix all android to androidx issues for React Native.
1. Please check that you have NPX installed and if not, install it with:
npm install -g npx

2. Add the following two flags to true in your gradle.properties file at ProjectFolder/android/gradle.properties

android.useAndroidX=true
android.enableJetifier=true

3. Execute these lines:

npm install --save-dev jetifier
npx jetify
npx react-native run-android

In your package.json add the following to scripts

  "postinstall" : "npx jetify"

Thats it, you are set, for more info, please go to https://github.com/mikehardy/jetifier

React Native Publishing an Android App

React Native and 64bit Android New Google Play rules. How to Solve?

Starting from August 1, 2019 Google Play will accept only 64-bit version of the application, so if you are lucky and have Android application written on Java or Kotlin — you can skip this article, otherwise— read further…

You can read more here in Google Blog.

DO NOT PANIC! I will explain what you need to do.

Episode 1. Small revision for latest news.

  • Changes in 2019:

Google is trying to move all mobile applications (except games written on Unity) to 64-bit support.

If you do not perform any actions:
– your application will still be available in the Google Play Market
– all updates that not support 64-bit will be ignored

That means that you will not be able to update an application unless you will add a 64 bit support version.

  • Changes in 2021:

All application that do not support a 64-bit version will not be available in the Google Play Market (including games written on the Unity engine)

  • Exceptions:
  1. Applications that are running on Android 8 Oreo or earlier do not need 64-bit support
  2. Android TV and Wear OS do not need 64-bit support (but that’s not quite ReactNative side, duh)

Episode 2. What to do?

Thank you Facebook and ReactCommunity! As of March 12, 2019, ReactNative has a new version release 0.59.

You can read the ReactNative 0.59 release notes here.

Yes, they added hooks, but the important thing here is 64-bit support on Android.

Sooo, the first and only step that you need to do is to update you ReactNative version to 0.59.1 or higher.

Important. Update must be done to at lease 0.59.1. This is related to missing commands for your application gradle.

If it is so important for you to have 0.59, there is some information presence of witch you need to verify, and if it is missing — then just add it.

Follow the official guide for update here to upgrade ReactNative or read below.

Steps are pretty simple:

  1. Just run:
react-native upgrade <version>

2. Resolve a conflict via git and voilà! And everything is ready.

When you are done let’s walk through the thing that should be in your ReactNative project.

We need to take a look on your ABI (Application Binary Interface) manager in Android project; basically these are directives to a device of what instruction set it should use.

Take a look at the file /android/app/build.gradle, we are interested in abiblock:

android {    ...   
 
    splits {
        abi {
            reset()
            enable enableSeparateBuildPerCPUArchitecture
            universalApk false
            include "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
        }
    }    // In case, if you're using `ndk`
    defaultConfig {
        ndk {
            // Tells Gradle to build outputs for the following ABIs and package
            // them into your APK.
            abiFilters "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
        }
    }    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            def versionCodes = ["armeabi-v7a":1, "x86":2, "arm64-v8a": 3, "x86_64": 4]
            def abi = output.getFilter(OutputFile.ABI)
            if (abi != null) { 
                output.versionCodeOverride =
                    versionCodes.get(abi) * 1048576 + defaultConfig.versionCode
            }
        }
    }    ...}

IMPORTANT. Insure that in include and versionCodes you have "arm64-v8a" and "x86-64".

IMPORTANT. If you’re using ndk, insure you have "arm64-v8a" and "x86-64" too.

Let’s walk through the ABI manager config to find out what’s happening there:

  • armeabi-v7a and x86 — support of instruction sets on x86 (32-bit) CPUs
  • arm64-v8a and x86-64— instruction sets for 64-bit CPUs

Thanks to these directives we are telling our application that it can run on 32 and 64-bit CPUs.

If there is something missing in you build.gradle just add it.

The important thing you need to know about multiple architecture support — it increase size of the your .apk file. No worries it have nothing to do with JS it self.

All you need to do is to bundle your Android application, it means replace your .apk with .aab .

If you followed ReactNative documentation about delivery to Google Play, most likely you used this command to build application:

./gradlew assembleRelease

You need to replace this command with:

./gradlew bundleRelease

This will create an .aab file and then you can do delivery as usual, but now you need to use App Signing by Google Play feature to sign you application and thats it.

How android bundle works you can react in official documentation here or you can read this article “Make your React Native app 3x smaller with one simple command” for more wide view.


I know that the ReactNative update can be painful, but new specifications of the Google Play Market are making us to do actualize of our projects. In the end, thanks to these changes, you will still have a good performance boost and hooks in your ReactNative project, so it is not high price to pay.

NGINX Let’s Encrypt Certbot Manual Installation

If you’re trying to update an outdated SSL certificate or even if you’re installing one for the first time and you don’t trust Certbot to modify your NGINX config for you then this article is for you.

Install Certbot

sudo apt-get update
sudo apt-get install software-properties-common
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install python-certbot-nginx

Download Certificate

The downloaded certificates and all other Let’s Encrypt/Certbot files will be written to /etc/letsencrypt

# The "certonly" flag is important it tells Certbot to only download the certificates
# and not to install them automatically by modifying your NGINX config

sudo certbot --nginx certonly

You will receive the message below after successfully running certbot

`privkey.pem`  : the private key for your certificate.
`fullchain.pem`: the certificate file used in most server software.
`chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
`cert.pem`     : will break many server configurations, and should not be used
                 without reading further documentation (see link below).

Manually Install Certificate

This was my old config with the outdated certificate.

server {
  listen 80;
  server_name canbyedfoundation.org www.canbyedfoundation.org;
  return 301 https://$server_name$request_uri;
}

server {
  listen 443 ssl;
  server_name canbyedfoundation.org www.canbyedfoundation.org;

  ssl on;
  ssl_certificate /etc/nginx/ssl/canbyedfoundation_org-bundle.crt;
  ssl_certificate_key /etc/nginx/ssl/canbyedfoundation.org.key;

  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
    proxy_pass http://127.0.0.1:8000;
    proxy_redirect off;
  }
}

To update the config I simply had to change the path to ssl_certificate and ssl_certificate_key

server {
  listen 80;
  server_name canbyedfoundation.org www.canbyedfoundation.org;
  return 301 https://$server_name$request_uri;
}

server {
  listen 443 ssl;
  server_name canbyedfoundation.org www.canbyedfoundation.org;

  ssl on;
  ssl_certificate /etc/letsencrypt/live/canbyedfoundation.org/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/canbyedfoundation.org/privkey.pem;

  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
    proxy_pass http://127.0.0.1:8000;
    proxy_redirect off;
  }
}

Verify Config File & Restart NGINX

sudo nginx -t && sudo nginx -s reload
React Native Publishing an Android App

React Native Publishing an Android App

Add/Create Keystore

This command will create a keystore with the given name if the file doesn’t exist or append a key to a current keystore.

keytool -genkey -v -keystore mykeystore.keystore -alias mykeyalias -keyalg RSA -keysize 2048 -validity 10000  

After you have generated the mykeystore.keystore file copy it to android/app.

Setting up gradle variables

Append the snippet below to android/gradle.properties and add the correct values.

MYAPP_RELEASE_STORE_FILE=mykeystore.keystore
MYAPP_RELEASE_KEY_ALIAS=mykeyalias
MYAPP_RELEASE_STORE_PASSWORD=*****
MYAPP_RELEASE_KEY_PASSWORD=*****

Adding signing config to your app’s gradle config

Edit android/app/build.gradle so it looks similar to the one below.

...
android {
    ...
    defaultConfig { ... }
    signingConfigs {
        release {
            storeFile file(MYAPP_RELEASE_STORE_FILE)
            storePassword MYAPP_RELEASE_STORE_PASSWORD
            keyAlias MYAPP_RELEASE_KEY_ALIAS
            keyPassword MYAPP_RELEASE_KEY_PASSWORD
        }
    }
    buildTypes {
        release {
            ...
            signingConfig signingConfigs.release
        }
    }
}
...

Add the siginingConfigs snippet right below but not in defaultConfig and then append signingConfig signingConfigs.release to buildTypes -> release.

Generating the release APK

cd android && ./gradlew assembleRelease

Testing the release build of your app

cd android && ./gradlew installRelease

Where is my bundled app?

The file you want to upload to the Google Play Store is android/app/build/outputs/apk/app-release.apk

Update version number for each build

In android/app/build.gradle increment:

versionCode 2
versionName "2.0"

Helpful Commands

# List aliases within a keystore with this command:
keytool -list -keystore mykeystore.keystore
Setting up a Cluster With Proxmox

How to setup NAT on Proxmox

Proxmox uses bridge networking to provide Internet access to virtual machines, but in a bridge networking you need a public IP for each machine. If you have limited IPs you can use NAT to access Internet on your machines. How ever it is preferable to have a static public IP if you are running public services like apache web server. Today we will see how to setup NAT on proxmox to provide private network for virtual machines.

Step 1: Create a bridge

Login to your proxmox host ssh, and run:

nano /etc/network/interfaces

This is your network configuration file for proxmox, you might see one bridged interface already configured (bridged to your physical interface), paste following at the end of your configuration file

  • vmbr2 : This is the bridge name for NAT.
  • vmbr1 : This is the interface that was already configured in your network file, adjust the name properly.
  • 192.168.1.0/24 : This will be the network we are going to use in our internal network, our usable ips in this network will be:
    • 192.168.1.2-192.168.1.254
    • If you plan to use different network, you can use this site to get help.
  • bridge_ports none : Bridge ports here is set to none, since we are not connecting to outside world directly.

You have successfully configured a NAT bridge.

Step 2: Bring up the NAT bridge

You can use this command to bring up the bridge you just created:

ifup vmbr2

This will bring up the bridge.

Step 3: Configure Virtual Machine

As a final step configure your virtual machine to use IP address, since DHCP is not present you will have to manually set IP address. Depending upon your OS you can use following details:

  • IP : 192.168.1.2
  • Gateway : 192.168.1.1
  • Netmask : 255.255.255.0

For further virtual machines you can use these ips:

  • 192.168.1.3
  • 192.168.1.4
  • ..upto 254

For DNS you can use google DNS

  • 8.8.8.8
  • 8.8.4.4

Step 4 : (Optional) Port forwarding to access from outside world

I am assuming you are working with linux guest. We will access ssh of our guest through public IP of main server.

Run this on proxmox host, we are forwarding host port 3033 to guest port 22. (SSH runs on 22)

Then run following to access guest SSH.

ssh -p 3033 [email protected]

It will ask for the password, once provided you will be successfully connected to guest SSH.

10 Tips to Get a 100% Site Health Score in WordPress 5.2

Converting between virtual image formats

qemu-img convert: raw, qcow2, qed, vdi, vmdk, vhd

The qemu-img convert command can do conversion between multiple formats, including qcow2qedrawvdivhd, and vmdk.

qemu-img format strings
Image formatArgument to qemu-img
QCOW2 (KVM, Xen)qcow2
QED (KVM)qed
rawraw
VDI (VirtualBox)vdi
VHD (Hyper-V)vpc
VMDK (VMware)vmdk

This example will convert a raw image file named image.img to a qcow2 image file.

$ qemu-img convert -f raw -O qcow2 image.img image.qcow2

Run the following command to convert a vmdk image file to a raw image file.

$ qemu-img convert -f vmdk -O raw image.vmdk image.img

Run the following command to convert a vmdk image file to a qcow2 image file.

$ qemu-img convert -f vmdk -O qcow2 image.vmdk image.qcow2

NoteThe -f format flag is optional. If omitted, qemu-img will try to infer the image format.

When converting an image file with Windows, ensure the virtio driver is installed. Otherwise, you will get a blue screen when launching the image due to lack of the virtio driver. Another option is to set the image properties as below when you update the image in the Image service to avoid this issue, but it will reduce virtual machine performance significantly.

$ openstack image set --property hw_disk_bus='ide' image_name_or_id

VBoxManage: VDI (VirtualBox) to raw

If you’ve created a VDI image using VirtualBox, you can convert it to raw format using the VBoxManage command-line tool that ships with VirtualBox. On Mac OS X, and Linux, VirtualBox stores images by default in the ~/VirtualBox VMs/ directory. The following example creates a raw image in the current directory from a VirtualBox VDI image.

$ VBoxManage clonehd ~/VirtualBox\ VMs/image.vdi image.img --format raw
Install Proxmox on Debian Wheezy

Migrating VirtualBox .vdi to ProxMox VE

  1. Find your VM’s .vdi file – First we need to locate the VirtualBox hard drive (.vdi) file.
    • Open the VirtualBox GUI
    • Click on the VM we want to migrate and click the Settings button
    • Click on Storage and click the .vdi file listed under IDE Controller
    • Mouse over the Hard Disk: dropdown list box and note the path to the .vdi file
  2. Convert the .vdi to .img – Next we need to convert the hard drive to a RAW format for ProxMox
    • On the VirtualBox host open a command prompt
    • Run
      Code:
      VBoxManage clonehd --format RAW [virtual_harddisk].vdi [virtual_harddisk].img
    • This may take a while so be patient. Go get some coffee.
  3. Create a new ProxMox VM – Next we need to create a Proxmox VM to hold our drive image.
    • Open up the Proxmox web interface
    • Click on Virtual Machines then click the Create tab
    • Leave all of the defaults. My Disk space (GB): was set to 32GB and my original .vdi was 20GB. This seems to have worked OK. I’ll edit if there are problems down the road.
    • Note the VMID: number of your new VM (i.e. « 106 »)
  4. Upload the .img file – now we need to upload the new /img file to the Proxmox server.
    • Start your file transfer softare (wither WinSCP or Filezilla are two good ones).
    • Transfer the .img file to the /var/lib/vz/images/106 folder (replace 106 with the number you noted from the VMID: field
  5. Rename the .img file – now all we need to do is rename the .img file
    • rename the existing .raw file (for instance vm-106-disk-1.raw) to .old
    • rename the .img file to the name of the existing .raw file (for instance vm-106-disk-1.raw)
  6. Boot it up!
Improving Website Performance – Enabling Keep-Alive

Improving Website Performance – Enabling Keep-Alive

How does Keep-Alive work?

In this tutorial you will learn 4 different methods to enable keep-alive. Keep-Alive allows a visitor’s browser to download all the content (such as JavaScript, CSS, images, videos and etc.) through a persistent TCP connection instead of making different requests for each file. This will provide a speed and performance boost as your visitor’s browser will be able to get everything through a single, persistent HTTP connection. In short, Keep-Alive is a communication pattern between a web server and a browser with the potential to drastically reduce request amount and speed up a web page. Here is a picture that will help in understanding the difference and benefits of Keep-Alive:

Advantages of enabling Keep-Alive:

  • Keep-Alive reduces the usage of CPU and memory due to a smaller amount of generated HTTP requests. This will benefit all hosting platform users (free hosting, shared hosting, VPS)
  • Enabling Keep-Alive provides HTTP pipelining (delivery of requests via same TCP connection)
  • HTTPS requests need more CPU time and resources. Keep-Alive will greatly benefit your website if you use HTTPS and SSL.
  • Reduced latency and overall increase in loading speed and performance.
  • Keep-Alive is supported by all modern browsers
  • Enabling Keep-Alive will also benefit your website in terms of SEO and ranking due to better site performance.

In short, Keep-Alive is a great way to reduce your resource usage while increasing your website speed at the same time.

What you’ll need

Before you begin this guide you’ll need the following:

  • Access to .htaccess file
  • Access to httpd.conf (optional)
  • Access to HttpCoreModule (optional)

Step 1 — Analyzing your site

Firstly, you should analyze a website with a tool such as GTMetrix to determine whether Keep-Alive is enabled or disabled on your server. Here are the results after analysis of a test page:

Keep-Alive not fully working

On some servers or hosting providers, Keep-Alive is enabled by default. If your analysis gives a 100% score, there is nothing more that needs to be done.

Step 2 — Enabling Keep-Alive

There are several ways to turn on Keep-Alive and it all depends on your server or hosting provider. Here are a few options:

Option 1 – Editing .htaccess file

To enable Keep-Alive, adding the following code to your .htaccess file should do the trick. Enabling Keep-Alive using .htaccess will override any server settings and enable the persistent connection.

<ifModule mod_headers.c>
Header set Connection keep-alive
</ifModule>

This method should work on most Linux shared hosting providers. In case you do not know where to find .htaccess, try referring to this tutorial.

Option 2 – Enabling Keep-Alive in Apache via httpd.conf file

If you have access to the Apache config file, you can enable the extension from there. Here is what the configuration should look like:

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 50

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 10
  • KeepAlive On section enables the extension.
  • MaxKeepAliveRequests section sets the max number of allowed requests for a single connection. 50 requests for one connection is a great place to start.
  • KeepAliveTimeout section specifies how long the server waits for new requests from a client. It is recommended to start with a smaller value such as 5 or 10 seconds and increasing it later if required. Settings this value too high can cause high server load.

If you cannot locate the httpd.conf file, run the following command in the command line:

find / -name httpd.conf

Option 3 – Enabling Keep-Alive in NGINX

Keep-Alive is enabled by default on NGINX, however, in some cases, it can be disabled. You can enable it using HttpCoreModule. Look for the value keepalive_disable, which is in a lot of cases the reason why Keep-Alive is not working. Before enabling it, make sure to know the reason why it’s disabled in the first place before attempting any changes.

Option 4 – Windows Server (IIS)

If you are using a Windows-based server, you can easily enable the Keep-Alive extension using the command line.

The following command will enable it:

appcmd set config /section:httpProtocol /allowKeepAlive:true

And if you wish to disable it, use:

appcmd set config /section:httpProtocol /allowKeepAlive:false

You can also refer to an official tutorial from Microsoft for a few extra options.
a

Step 3 — Testing the changes

Once Keep-Alive is fully enabled, run another scan with GTMetrix or any other website performance analysis tool to see if everything is working. Here are the results after Keep-Alive has been turned on:

Keep-Alive fully functional

It is also possible to check whether Keep-Alive is functioning by checking your HTTP header. This can be done via terminal using the following command:

curl -I http://example.com/example.php

Here is an example:

curl -i http://hostinger.com/index.php

The results are:

HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Server: nginx
Date: Fri, 23 Dec 2016 18:58:14 GMT
Content-Type: text/html
Content-Length: 178
Location: https://www.hostinger.com/index.php

The Connection: keep-alive part signifies that Keep-Alive is functional.

Conclusion

To sum up, enabling Keep-Alive for your website is a great way to improve speed and performance. The persistent TCP connection will ensure faster load times and higher efficiency, thus keeping your visitors happy.

Install Proxmox on Debian Wheezy

Proxmox Networking

This time, I would like to show how Proxmox networking configuration can be configured. In my last post, I showed, how to install Proxmox and get ready to create VM’s. I will show a typical configuration, which I always use. The official documentation can be found here:

Proxmox Network Model

I will show, how to configure the network connection for the Proxmox host itself and how to separate the VM traffic from the host traffic using VLAN’s.

Proxmox Networking: Management Traffic

To use the Proxmox host, you must be able to manage it somehow. If you have only one network interface, as I in my test lab, you can use the native network interface for the management and guest traffic. There is no spacial configuration needed. If yo have more than one network card I would recommend to use one for the host management and the other(s) network card(s) for the guest traffic.

Proxmox Networking: Bridged VM Traffic

This type is used to directly connect the VM’s to your network. If you have two or more network cards in your system, you should use a different network card then the one used for management traffic to separate the guest traffic from the management traffic.

To create a bridged networking, you have to create a virtual network card. You can use the web GUI of Proxmox for this, but I prefer to use the CLI. Login to your host, using ssh and open this file:

vi /etc/network/interfaces

Just create a new virtual network interface by adding those lines:

auto vmbr1
iface vmbr1 inet manual
 bridge_ports eth1
 bridge_stp off
 bridge_fd 0

This will create “vmbr1” which is bound to the “eth1” interface. I will not assign an IP address to the “eth1” or the “vmbr1” interface. This way, the guest VM’s are not able to connect to the host directly.

If you have no separate interface, you can either bound the virtual network card to the available interface like this:

auto eth0
iface eth0 inet static

auto vmbr1
iface vmbr1 inet static
 address 10.3.5.1
 netmask 255.255.255.0
 bridge_ports eth0
 bridge_stp off
 bridge_fd 0

You have to assign the IP address which is used for “eth0″ to vmbr1”.

You can also use VLAN’s to separate the traffic, even if you only have one network interface. This can be configured this way:

auto vmbr1
iface vmbr1 inet manual
 bridge_ports eth0.10
 bridge_stp off
 bridge_fd 0

Creating “vmbr1” and binding it to “eth0.10” will create the tagged VLAN 10 on “eth0”. You have to configure the Switch port with the same setting. All VM’s bound to this virtual bridge interface, will be placed into VLAN 10.

Proxmox Networking: Host Only Network

If you need to connect VM’s directly on the host, without sending the traffic to the external world, you can use host only networks. You have to create another virtual bridge interface, but this time, you did not have to bind it to a physical network interface.

Open this file again:

vi /etc/network/interfaces

Add the following lines to the file:

auto vmbr1
iface vmbr1 inet static
 bridge_ports none
 bridge_stp off
 bridge_fd 0

All VM’s connected to this interface will be able to talk to each other. They will not be able to connect to the external world using this interface.

Proxmox Networking: Routed Networking

If you would like to hide your VM’s behind the host IP you can use a routed networking configuration. You have to create another virtual network interface and enable routing on this interface.

Open this file again:

vi /etc/network/interfaces

When working with a routed configuration, you need to enable proxy arp on the outgoing interface. In my scenario, this is “eth0”:

auto eth0
iface eth0 inet static
 post-up echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

To create the virtual interface and enable routing add those lines:

auto vmbr1
iface vmbr1 inet static
 address 10.3.5.1
 netmask 255.255.255.0
 bridge_ports none
 bridge_stp off
 bridge_fd 0
 post-up echo 1 > /proc/sys/net/ipv4/ip_forward

The last line will enable routing on the interface. With this configuration the VM traffic will routed using the routing table of the host. The outside world needs to know, how to reach the “10.3.5.0/24” subnet. To avoid working with static routes, you could NAT the traffic. This will hide the “10.3.5.0/24” subnet behind the IP address of the Proxmox host. To enable the NAT function add those lines to the virtual network interface:

post-up iptables -t nat -A POSTROUTING -s '10.3.5.0/24' -o eth0 -j MASQUERADE
 post-down iptables -t nat -D POSTROUTING -s '10.3.5.0/24' -o eth0 -j MASQUERADE

This will enable the NAT function for the internal network “10.3.5.0/24” by using “eth0” as the egress network.

From my point of view, this describes the three main Proxmox networking options. There are other options, e.g. using a virtual switch or router on the host.

Install Proxmox on Debian Wheezy

Install Proxmox on Debian Wheezy

In this post, I would like to show how to install Proxmox on debian Wheezy. Proxmox is a web-based GUI for KVM. I use this in my LAB for all the software related testing. It is free, but you can also get commercial support. It is one of those great open source tools.

Check Requirements

Before you can start the installation, you should check if your host is able to install Proxmox. You should have the latest version of Debian Wheezy, Debian Jessie is currently not supported by Proxmox.

You should also check, if your CPU is able to run KVM based virtual machines. You have to enable “vmx” “Intel VT-x” for Intel CPU’s and “svm” “AMD SVM” for AMD based CPU’s. Afterwards you can check if it is enabled by looking into /proc/cpuinfo

grep --color vmx /proc/cpuinfo

or

grep --color svm /proc/cpuinfo

For an intel CPU it could look like this:

Intel-VMX-support
Intel-VMX-support

I do not have any AMD based system to get a sample output, but it should look similar.

You should also make sure, that you have the correct settings in your hosts file. It should look like this:

127.0.0.1 localhost
192.168.2.10 proxmox.hpn.local proxmox

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

If you can make a check mark on the above requirements, head over to the next step.

Install Proxmox

To install proxmox on your system, you have to add the repository to your source list:

vi /etc/apt/sources.list

Add the following line:

# PVE repository provided by proxmox.com, only for installation (this repo will stay on 3.1)
deb http://download.proxmox.com/debian wheezy pve

Before you can use this repository, you ave to import the repository key:

wget -O- "http://download.proxmox.com/debian/key.asc" | apt-key add -

Update your system:

apt-get update && apt-get dist-upgrade

This will fetch the information from the added repository and install the proxmox kernel.

If not automatically done with the update above, install the Proxmox kernel:

apt-get install pve-firmware pve-kernel-2.6.32-26-pve

Now, the tricky part starts. If you have no physical access to the server, you need to be very careful with the next step. It could happen that you machine will not boot correctly.

You have to configure grub that way, that the Proxmox kernel is loaded automatically. During the installation of the Proxmox kernel, you will see those lines:

Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
Found linux image: /boot/vmlinuz-2.6.32-26-pve
Found initrd image: /boot/initrd.img-2.6.32-26-pve
done

This will tell, which options are available at the boot screen. The default value for grub is “0”. This means, that the first line is option “0”. You should boot line number “3”, which means we need to tell grub to use option “2” for default. To change the default option open this file:

vi /etc/default/grub

Look for this entry:

GRUB_DEFAULT=0

I have to change it to “2”:

GRUB_DEFAULT=2

Save the file and update grub with the new configuration:

# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
Found linux image: /boot/vmlinuz-2.6.32-26-pve
Found initrd image: /boot/initrd.img-2.6.32-26-pve
done

Using this command will also bring up all boot options, if you missed it in the first place.

You can now reboot your system.

If you system is back online, you can check if the correct kernel was booted by:

uname -a
Linux 2.6.32-26-pve #1 SMP Mon Oct 14 08:22:20 CEST 2013 x86_64 GNU/Linux

The important part is “-pve”.

You can now remove the debian default kernel by:

apt-get remove linux-image-amd64 linux-image-3.2.0-4-amd64 linux-base

If you do so, you have to change the grub configuration again.

Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.32-26-pve
Found initrd image: /boot/initrd.img-2.6.32-26-pve
done

For me, it is now “0” again.

The last step, is to install the rest of the Proxmox files:

apt-get install proxmox-ve-2.6.32 ntp ssh lvm2 postfix ksm-control-daemon vzprocps open-iscsi bootlogd

This will install a lot of packages.

You can now remove the Proxmox repository from your source list again. If you do not have a commercial support contract you have to remove the commercial repository from your system. Therefore open this file:

# vi /etc/apt/sources.list.d/pve-enterprise.list

and remove those lines:

deb https://enterprise.proxmox.com/debian wheezy pve-enterprise

and add those lines:

# PVE pve-no-subscription repository provided by proxmox.com, NOT recommended for production use
deb http://download.proxmox.com/debian wheezy pve-no-subscription

Update the system to the latest Proxmox version:

# apt-get update && apt-get dist-upgrade

As this will install a newer kernel version, reboot the last time.

You can now access the GUI of Proxmox by using this url:

https://your-ip-address:8006

You can use your root credentials, to login to the system.

The next step would be to create networking for the VM’s. I will write a post about the network configuration next time.