Category Archives: How-to

Start/ Stop Container Using The Proxmox Web API in Bash

Tags :

Category : How-to

Get Social!

The Proxmox Web API can perform any actions available in the front end Web. By implementing a REST API, all commands have been exposed and can be used programatically.

In this example we’ll use Bash to call the Proxmox Web API with our authentication token to start and stop an existing LXC Container.

See this post for an introduction to the Proxmox Web API, including all available API commands.

To issue API requests you’ll need to ensure you have already generated an authentication ticket which is described in Parse Proxmox Web API authentication ticket and the CSRFPreventionToken in Bash.

Once you have the authentication ticket you’ll need to call the Proxmox API using curl and parse the result. Use the below scripts and substitute the values as required:

Start an LXC Container

  • TICKET is the authentication ticket that was produced in the Parse Proxmox Web API authentication ticket and the CSRFPreventionToken in Bash post. Ideally you would programatically call the authentication routine and then pass the values straight into the below API calls.
  • CSRF is produced in the same way as TICKET. It’s actually only required when writing data to the API but there is no harm in always including it.
  • HOST is the host or IP address of the Proxmox server.
  • NODE is the node name of the Proxmox server that the LXC Container resides on.
  • TARGET_VM  is the VMID of the LXC Container.
TICKET=[security-ticket]
CSRF=[csrf-token]
HOST=prox-node1
NODE=prox-node1
TARGET_VMID=100

START_TASK_DATA=`curl -s -k -b "PVEAuthCookie=$TICKET" -H "CSRFPreventionToken: $CSRF" -X POST $HOST/api2/json/nodes/$NODE/lxc/$TARGET_VMID/status/start`

START_TASK_RESULT=$(decodeDataFromJson $START_TASK_DATA 'data')

If $START_TASK_RESULT doesn’t come back with null or empty then the command has successfully executed.

Stop an LXC Container

Stopping a VM in Proxmox is very similar to starting one, with just a slight change to the API URL call. All other options are the same as the above section ‘Start an LXC Container’.

TICKET=[security-ticket]
CSRF=[csrf-token]
HOST=prox-node1
NODE=prox-node1
TARGET_VMID=100

STOP_TASK_DATA=`curl -s -k -b "PVEAuthCookie=$TICKET" -H "CSRFPreventionToken: $CSRF" -X POST $HOST/api2/json/nodes/$NODE/lxc/$TARGET_VMID/status/stop`

STOP_TASK_RESULT=$(decodeDataFromJson $STOP_TASK_DATA 'data')

If $STOP_TASK_RESULT doesn’t come back with null or empty then the command has successfully executed.

Getting Started With Proxmox HTTP API Commands

Tags :

Category : How-to

Get Social!

Proxmox has 2 API access points that can be used to control your Proxmox server and virtual guests. One of the API access points is using the command line, which you’re likely already familiar with. The other is the HTTP web API which is exposed as part of the WEB GUI on port 8006.

The Proxmox uses a JSON data format for returning data that can easily be parsed programmatically. Every command available to the pvesh command line command are available to the web based API as they share the same endpoint.

The endpoint for the Web API can be called using anything that can send and receive web based requests. We’ll use curl for the below examples. The endpoint to call would be similar to below – be sure you substitute yourip for the IP or hostname of your Proxmox server.

https://yourip:8006/api2/json/

API Authentication

The next step is to authenticate your API requests with the Proxmox server. API authentication uses the same mechanism that logging into the Web GUI uses and requires a username, password and security realm.

Authentication is based on a token method which provides a ticket that must accompany all API requests except for the request that generates the token. A username and password will not be accepted for authentication with all other API requests. In addition, any requests that POST or write to the API endpoint must contain a CSRF Prevention Token.

To obtain an authentication token, run the below curl command and substitute your values as required – this example uses the root user and the default PAM realm.

curl https://yourip:8006/api2/json/access/ticket -k -d 'username=root@pam&password=PASSWORD'

Example output:

{  
  "data":{  
    "CSRFPreventionToken":"5922F2C4:e7n+eQ9Lipbga3bY00Jh79MBATk",
    "username":"root@pam"
    },
    "ticket":"PVE:J38560@AD:5922F2C4::oOAcgXvCcAdLG+B50sRZ9WeaKn3gCFEktnHtegUVEcdtYO0NE7THA7pmzKZ14MgOYrp6vrye4ZBDocpu/nhuvUUL3vZeAT7YMstBXR3YLN8IlwQl5HJdgOikdz+gMdWyfx3JxcNhaNpJlHDL8Vm7D0r7GKGsHPirB098eG7pg1MgrkW7U6R5piW66c/p3kdJvT5beD+IPOhst76SoVlFo3ZxFFcqpcD5RFsUpKl9K1/5tgPReh1sErcDhOgUeiAE5XZHFsTE/jBVeSv9O2cXb5fESRtTU3986Gtw85hPJlWDzMz+X94H0rlL25cYkIbnOx5KJi9IcNTnvTHdpaoXuQ=="
}

The two interesting parts here are the ticket value and the CSRFPreventionToken and should be parsed out for use in later requests.

A token is valid for 2 hours and should be re-requested when it expires. Alternatively each request could generate it’s own token, however this generates added overhead.

List of Proxmox API Requests

pvesh is a command line utility can be used to perform the same actions as the web based API. You can, therefore, use the pvesh command to list all the possible API calls and navigate through the API call tree.

# pvesh
entering PVE shell - type 'help' for help
pve:/> 

pve:/> ls
Dr--- access
Dr--- cluster
Dr--- nodes
Dr-c- pools
Dr-c- storage
-r--- version

pve:/>cd nodes

pve:/nodes>ls
Dr--- prox-node1

You can then list the available commands from the root of the API using ls and then change into one of the child paths using cd. You can navigate throughout the whole API tree using these two methods to see what commands are available for calling. This is often the best way to get started with the Proxmox API.

Examples of API Requests

As stated earlier, all operations available in the Proxmox Web GUI can be performed through the API. Here are a few examples of API requests using Bash:

Parse Proxmox Web API authentication ticket and the CSRFPreventionToken in Bash

Tags :

Category : How-to

Get Social!

The Proxmox Web API can perform any actions available in the front end Web. By implementing a REST API, all commands have been exposed and can be used programatically.

The API is secured using a token based method which provides a ticket that must accompany all API requests except for the request that generates the token. The token is generated from an API call containing a username, password and security realm.

In this example we’ll use Bash to call the Proxmox Web API, authenticate with the root Proxmox user and parse the response for use in later API requests. Note that it’s not good practice to use the root account for API calls due to the security implications.

See this post for an introduction to the Proxmox Web API.

Add this function to the top of your Bash script. This will be used to parse the JSON using standard Bash calls to obtain the information we need.

decodeDataFromJson(){
    echo `echo $1 \
	    | sed 's/{\"data\"\:{//g' \
	    | sed 's/\\\\\//\//g' \
	    | sed 's/[{}]//g' \
            | awk -v k="text" '{n=split($0,a,","); for (i=1; i<=n; i++) print a[i]}' \
	    | sed 's/\"\:\"/\|/g' \
	    | sed 's/[\,]/ /g' \
	    | sed 's/\"// g' \
	    | grep -w $2 \
	    | awk -F "|" '{print $2}'`
}

The next step is to call the Proxmox API using curl to obtain our authentication token. Use the below script and substitute the values as required:

  • PROX_USERNAME is the username and security realm used to log into the Proxmox Web front end. This must be a valid user with the required permission to make the calls you need.
  • PROX_PASSWORD is the password for the above user. You must escape any special characters as usual in Bash.
  • HOST is the host or IP address of the Proxmox server.
PROX_USERNAME=root@pam
PROX_PASSWORD=PASSWORD
HOST=proxmox-host

DATA=`curl -s -k -d "username=$PROX_USERNAME&password=$PROX_PASSWORD" $HOST/api2/json/access/ticket` 
TICKET=$(decodeDataFromJson $DATA 'ticket')
CSRF=$(decodeDataFromJson $DATA 'CSRFPreventionToken')

And that’s all there is to it! You can use the variables $TICKET and $CSRF in later requests. Keep in mind that a valid ticket is only valid for 2 hours, after that you’ll need to create a new one.

Virgin Media Speeds In Nottingham

Tags :

Category : How-to

Get Social!

Somewhat off-topic today, but something that I’ve recorded here to showcase the current state and see if anyone else is getting similar issues.

A colleague of mine and I have been measuring our broadband speeds since the start of the year. We both live in Nottingham and pay for a residential Virgin Media 200mbps line which I pay approximately £45 each month.

Given the data logged, we’ve concluded that our upload is typically fine at 12mbps but the download varies massively – to the point where single session streaming from Youtube/Netflix is unusable.

This graph shows average download speed per hour which clearly shows the drop during the ‘busy period’

This next one shows the number of counts recorded at a given speed range for the best time (5am) and worse time (9pm). As you can see at 9pm I mostly get between 30mbps and 80mbps

Another way to look at this is via a heatmap showing counts for all speed groups by hour:

We then wondered what the cost implication of this could be, if we only paid for what we got. The table below shows calculations of the cost impact. It is based on cost per month divided by 24 (number of hours) then working out the modified hourly rate based on that percentage.

Being fair, I would ignore speeds where the fluctuation is less than 20% and pay the full price for that hour. An 80% drop in speed is perfectly reasonable in my book and something that probably wouldn’t be noticed by most people. Using the above calculation the result would be a cost of £33.42, meaning I’m overcharged by ~35%.

These are average speeds, and as shown above the download speed can be much lower than this average and it’s at these points the impact to me is most interruptive to me and this cost isn’t reflected above.

How are other peoples download speeds stacking up?

Simple iptables Rules for Ubuntu/ Debian VPS

Tags :

Category : How-to

Get Social!

The following iptables rules are are a starting point to add basic firewall security to a public facing server, such as a public VPS. The primary focus is to stop any inbound traffic other than SSH, which is required for shell access.

[the_ad id=”2698″]

The biggest issue with public VPS providers is that often some iptables features are disabled – many OpenVZ container providers don’t allow state checking in iptables, for example. If you’ve got one of these VPS’s you’ll likely see the following error:

iptables: No chain/target/match by that name.

These rules are engineered so that they will work with most VPS’s where iptables is installed.

The following rules will block all incoming connections except SSH, including PING requests. Outgoing is open for HTTP and HTTPS TCP requests and DNS UDP requests.

See the links at the bottom of the page for a more in depth look at iptables rules.

# Loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Inbound SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

# Outbound HTTP/S
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --sport 443 -j ACCEPT

# Outbound DNS
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT

# default policy
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

If you’re using Ubuntu, you can easily make the rules persist:

apt-get install iptables-persistent
service iptables save

 

Setting Memory Resource Limits With LXC

Tags :

Category : How-to

Get Social!

linux_containers_logo

 

Linux Container (LXC) management is now often dealt with by LXD, the Canonical lead project built on top of LXC.

LXD offers a suite of options for controlling Linux Container resources and setting limits where appropriate. This post will talk about setting constraints on CPU, however other options are available for limiting almost any sort of resource, such as network, disk I/O, memory and so on.

Available Limits

CPU management is done in 1 of 4 ways, depending on your expected workload and host CPU management regime.

  1. Number of CPUs – set the number of CPU cores that LXC can use with this container and automatically distribute CPU time amongst guests when there is competition for CPU time. The value used is an integer, for example 2.
  2. Specific cores – specify specific physical core(s) for the container to use and distribute available CPU time between containers when multiple containers use the same cores.The value used is an integer or range and can be comma separated, for example 2, 0-1 or 0-1,3,5-9.
  3. Capped share – allow a specified percentage of CPU time for the container, or more if it’s available. When the host is not under load then a container can use any available CPU however when there is contention for CPU then the container will be limited to the specified amount. The container will see all host CPU cores (in TOP, for example).
  4. Limited time share – will limit the container CPU time to be whatever is specified out of each 200ms. Even if more CPU is available, only what is specified per 200ms slice is allowed. The container will see all host CPU cores (in TOP, for example).

Setting Limits

Setting limits is done with the lxc command. There are then two options; limits.cpu for the above points 1 and 2, or limit.cpu.allowance for points 3 and 4.

lxc config set [CONTAINER] limits.cpu [VALUE]
  • [CONTAINER] is the name of the container – can be obtained from lxc list if you’re unsure.
  • [VALUE] is a valid value from point 1 or 2 above.

OR

lxc config set [CONTAINER] limits.cpu.allowance [VALUE]
  • [CONTAINER] is the name of the container – can be obtained from lxc list if you’re unsure.
  • [VALUE] is a valid value from point 3 or 4 above.

CPU Limit Examples

Set the container nginx-proxy to use any 2 CPUs on the host.

lxc config set nginx-proxy limits.cpu 2

Set the container nginx-proxy to use physical CPU 0, 3, 7, 8 and 9 on the host.

lxc config set nginx-proxy limits.cpu 0,3,7-9

Set the container nginx-proxy to use 20% of the available CPU on the host or more if it’s available.

lxc config set nginx-proxy limits.cpu.allowance 20%

Set the container nginx-proxy to use no more than 50% of the available CPU on the host, or 100ms for every 200ms of CPU time available.

lxc config set nginx-proxy limits.cpu.allowance 100ms/200ms

You can view /proc/cpuinfo to see the available cores on your container, however it will not include any additional scheduling limits or priorities.

cat /proc/cpuinfo | grep processor
processor: 0
processor: 1

CPU Priority

The last option around CPU limiting is the priority of CPU time. This option only kicks in when the host is overcommitted on CPU resource and containers are fighting for CPU time. This can either be on a single core (if using above points 1 or 2) or system wide (if no CPU limiting is in place or using above points 3 or 4).

Available values are 0 – 10 inclusive and lower numbers mean a lower priority – a higher number will mean the machine gets CPU time before lower numbers.

The below command sets the container nginx-proxy to have a CPU priority of 5.

lxc config set nginx-proxy limits.cpu.priority 5

The below command sets the container php-backend to have a CPU priority of 2 and therefore would get less CPU time than container nginx-proxy when CPU is under contention.

lxc config set php-backend limits.cpu.priority 5
« Previous Page — Next Page »

Visit our advertisers

Search

Quick Poll

How many Proxmox servers do you work with?
Results

Recent Posts

Visit our advertisers

Site Links
Blog
Rated Sites

JamesCoyle.net Limited