Guacamole is a clientless remote desktop gateway. After successful implementation of this system on some PCs, now I want to use this on a Raspberry Pi 3 B+. Following is how I do the installation on Raspbian system.

OS Version: Raspbian GNU/Linux 9 (stretch)
  1. Upgrade the system:
$ sudo apt-get update
$ sudo apt-get upgrade
  1. Install the required dependencies:
$ sudo apt-get install libcairo2-dev
$ sudo apt-get install libjpeg62-turbo-dev
$ sudo apt-get install libpng12-dev
$ sudo apt-get install libossp-uuid-dev
  1. Install the optional packages:
$ sudo apt-get install libavcodec-dev libavutil-dev libswscale-dev
$ sudo apt-get install libpango1.0-dev
$ sudo apt-get install libssh2-1-dev
$ sudo apt-get install libtelnet-dev
$ sudo apt-get install libvncserver-dev
$ sudo apt-get install libpulse-dev
$ sudo apt-get install libssl-dev
$ sudo apt-get install libvorbis-dev
$ sudo apt-get install libwebp-dev
  1. Download Guacamole Server and Client packages:
$ wget http://sourceforge.net/projects/guacamole/files/current/source/guacamole-server-0.9.14.tar.gz
$ wget http://sourceforge.net/projects/guacamole/files/current/source/guacamole-client-0.9.14.tar.gz
  1. Build and install the server:
$ tar xzf guacamole-server-0.9.14.tar.gz
$ cd guacamole-server-0.9.14
$ ./configure --with-init-dir=/etc/init.d
$ make
$ sudo make install
$ sudo update-rc.d guacd defaults
$ sudo ldconfig
  1. Build the client:
$ sudo apt-get install maven
$ tar xzf guacamole-client-0.9.14.tar.gz
$ cd guacamole-client-0.9.14
$ mvn package
  1. Install jetty9 servlet container:
$ sudo apt-get install jetty9
  1. Deploy Guacamole:
$ sudo cp guacamole/target/guacamole-0.9.14.war /var/lib/jetty9/webapps/guacamole.war
$ sudo mkdir -p /etc/guacamole/extensions
$ sudo cp extensions/guacamole-auth-noauth/target/guacamole-auth-noauth-0.9.14.jar /etc/guacamole/extensions/.
  1. Copy following text and save it as “/etc/guacamole/guacamole.properties”
#    Guacamole - Clientless Remote Desktop
#    Copyright (C) 2010  Michael Jumper
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU Affero General Public License as published by
#    the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU Affero General Public License for more details.
#
#    You should have received a copy of the GNU Affero General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>.

# Hostname and port of guacamole proxy
guacd-hostname: localhost
guacd-port:     4822

# Auth provider class (authenticates user/pass combination, needed if using the provided login screen)
auth-provider: net.sourceforge.guacamole.net.basic.BasicFileAuthenticationProvider
basic-user-mapping: /etc/guacamole/user-mapping.xml

# NoAuth properties
noauth-config: /etc/guacamole/noauth-config.xml
  1. Copy following text and save it as “/etc/guacamole/noauth-config.xml”
<configs>
    <config name="pi" protocol="vnc">
        <param name="hostname" value="localhost" />
        <param name="port" value="5900" />
    </config>
</configs>
  1. Copy following text and save it as “/etc/guacamole/user-mapping.xml”. The password is “raspberry”.
<user-mapping>
    <authorize 
    username="pi"
    password="b89749505e144b564adfe3ea8fc394aa"
    encoding="md5">
        <connection name="pi">
        <protocol>vnc</protocol>
        <param name="hostname">localhost</param>
        <param name="port">5900</param>
        <param name="swap-red-blue">false</param>
        <param name="enable-audio">true</param>
        </connection>
    </authorize>
</user-mapping>
  1. Install x11vnc VNC-Server:
$ sudo apt-get install x11vnc
  1. Copy following text and save it as “~/.config/autostart/x11vnc.desktop”
[Desktop Entry]
Name=X11 VNC
Comment=Remotedesktop Server
Exec=x11vnc -forever -nopw -rfbport 5900 -display :0
Terminal=false
Type=Application
X-MATE-Autostart-enabled=true
Comment[de_DE]=Remotedesktop Server
  1. Restart Raspberry Pi:
$ sudo reboot

At this point guacamole should be automatically started at system boot. You can try to open it from a web-browser, the address is “<ip-address>:<port>/guacamole”. On my network it looks like this “192.168.178.100:8080/guacamole”.

In case you use headless system (Raspberry Pi without display attached) and you have poor display resolution, you can set the parameters in “/boot/config.txt” from this:

#framebuffer_width=1280
#framebuffer_height=720

#hdmi_force_hotplug=1

to this (for full HD resolution):

framebuffer_width=1920
framebuffer_height=1080

hdmi_force_hotplug=1

Restart the system and that’s it. Have fun!

Reference: http://www.m-opensolutions.com/?p=936

Incoming search terms:

  • raspbian desktop x86 guacamole

The infamous heat issue with the Odroid HC2 is here. My simple solution is simply by plugging in cheap USB fan to the bottom of the case (I put my HC2 vertically for better heat dissipation). Below is the result.

CPU thermal reduction
3.5 HDD thermal reduction

And for the sake of comparison, here’s the CPU thermal reading for my RPi2 with no cooling (and running Node JS + Munin server)

Raspberry Pi 2 in a case, no fan

I found a great web based monitoring tools for this smart plug, and I will share my method running this tools in Raspberry Pi (with DietPi).

Read more about this tool here: https://github.com/jamesbarnett91/tplink-energy-monitor

There are few method to run this, but I found that using Node+NPM is the easiest for this platform.

apt install git npm
git clone https://github.com/jamesbarnett91/tplink-energy-monitor && cd tplink-energy-monitor
npm install
npm start

Once installed and run, go to http://server-ip:3000

Here’s the situation. I have an Odroid XU4 and Raspberry Pi, both of them running with DietPi image. The mission is to perform system monitoring for both of the system.

Install Munin server

Ensure that the system is up to date before you start to install Munin, run:

apt-get updateapt-get upgrade

Apache is used to show the Munin pages, the apache fcgid module is required for the Munin graph zoom feature. Install apache and the fcgid module with apt.

apt-get install apache2 libcgi-fast-perl libapache2-mod-fcgid

Enable the fcgid module in apache.

a2enmod fcgid

Install & Configure Munin

To install Munin on DietPi, we do this:

apt-get install munin munin-node munin-plugins-extra 

Next, we must edit the Munin configuration file /etc/munin/munin.conf. Uncomment the dbdirhtmldirlogdirrundir, and tmpldir lines (the default values are fine). We want Munin to use the name raspiblack.local instead of localhost.localdomain in the HTML output, therefore we replace localhost.localdomain with raspiblack.local in the simple host tree section. Without the comments, the changed file looks like this:

nano /etc/munin/munin.conf
# Example configuration file for Munin, generated by 'make build'

# The next three variables specifies where the location of the RRD
# databases, the HTML output, logs and the lock/pid files. They all
# must be writable by the user running munin-cron. They are all
# defaulted to the values you see here.
#
dbdir /var/lib/munin
htmldir /var/cache/munin/www
logdir /var/log/munin
rundir /var/run/munin

# Where to look for the HTML templates
#
tmpldir /etc/munin/templates

# Where to look for the static www files
#
#staticdir /etc/munin/static

# temporary cgi files are here. note that it has to be writable by
# the cgi user (usually nobody or httpd).
#
# cgitmpdir /var/lib/munin/cgi-tmp # (Exactly one) directory to include all files from. includedir /etc/munin/munin-conf.d [...] # a simple host tree
[raspiblack.local]
address 127.0.0.1
use_node_name yes
[XU4.local]
address 192.168.1.6
use_node_name yes [...]

Run these commands to enable and load the configuration into apache.

cd /etc/apache2/conf-enabled/ln -s /etc/munin/apache24.conf munin.confservice apache2 restart

Make sure you comment out the line Require local and add Require all granted and Options FollowSymLinks SymLinksIfOwnerMatch instead (otherwise you will only be able to access the Munin output from localhost):

nano /etc/munin/apache24.conf
Alias /munin /var/cache/munin/www
<Directory /var/cache/munin/www>
 # Require local
 Require all granted
 Options FollowSymLinks SymLinksIfOwnerMatch
 Options None
</Directory>

ScriptAlias /munin-cgi/munin-cgi-graph /usr/lib/munin/cgi/munin-cgi-graph
<Location /munin-cgi/munin-cgi-graph>
 # Require local
 Require all granted
 Options FollowSymLinks SymLinksIfOwnerMatch
 <IfModule mod_fcgid.c>
 SetHandler fcgid-script
 </IfModule>
 <IfModule !mod_fcgid.c>
 SetHandler cgi-script
 </IfModule>
</Location>

Restart Apache:

service apache2 restart

Then restart Munin:

service munin-node restart

Install munin node on XU4

apt-get install munin-node munin-plugins-extra 

Edit munin node configuration

nano /etc/munin/munin-node.conf

Change munin node identification and allow probe

host_name XU4.local 
allow ^192\.168\.1\.230$

192.168.1.230 is the address of the munin server

Then restart Munin:

service munin-node restart

Now wait a few minutes so that Munin can produce its first output, and then go to http://munin-server-ip-address/munin/ in your browser, and you see the first statistics.

References:
https://www.howtoforge.com/tutorial/server-monitoring-with-munin-and-monit-on-debian/

https://www.digitalocean.com/community/tutorials/how-to-install-the-munin-monitoring-tool-on-debian-8

Types of dynamic routing protocols:

 

RIP : Routing Information Protocol - AD 120
IGRP : Interior Gateway Routing Protocol - AD-100
EIGRP : Enhanced IGRP AD-90
OSPF : Open Shortest Path First AD-110
IS-IS : Intermediate system to intermediate system AD-115
BGP: Border Gateway Protocol AD-20

Comparison

Property   EIGRP OSPF  BGP
Administrative Distances Internal – 90
External 170
110 EBGP – 20
IBGP – 200
Method   Advanced distance vector  Link state Path vector
Summarization   Auto and manual Manual Auto and Manual
VLSM  Yes Yes Yes
Convergence Speed    Very fast convergence Fast Slow
Timers: Update
(hello/dead)    
Triggered (LAN 5/15, WAN 60/180)  Triggered when network change occurs, send periodic update LSA refreshes every 30 minutes (NBMA 30/120, LAN 10/40) Triggered (60/180)
Network Size  Large Large Very large
Mixed-Vendor Devices No Yes Yes
Use multicast  224.0.0.10 224.0.0.5  
Feature  – Partial updates conserve network bandwidth
– Support for IP, AppleTalk, and IPX
– Runs directly over IP, using protocol number 88
– Support for all Layer2 (data link layer) protocols and topologies
– Load balancing across equal-and unequal-cost pathways
– Multicast and unicast instead of broadcast address
– Support for authentication
– Manual summarization at any interface
– 100% loop-free classless routing
 – Minimizes the number of routing table entries
– Contains LSA flooding to a reasonable area
– Each routing device takes a copy of the LSA updates its LSDB and forward the LSA to all neighbor devices within area
– Minimizes the impact of a topology change
– Enforces the concept of a hierarchical network design
 – BGP provides the routing betw these autonomouse systems.
– BGP uses the concept of autonomous systems (AS). An autonomous system is a group of networks under a common administration. The Internet Assigned Numbers Authority (IANA) assigns AS numbers: 1 to 64511 are public AS
numbers and 64512 to 65535 are private AS numbers.
– IGP: A routing protocol that exchanges routing infor within AS. RIP, IGRP, OSPF, IS-IS and EIGRP are examples of IFPs.
– EGP: A routing protocol that exchanges routing infor betw different AS. BGP is an example of an EGP.
– The administrative distance for EBGP routes is 20. The administrative distance for IBGP routes is 200.
– BGP neighbors are called peers and must be statically configured.
– BGP uses TCP port 179. BGP peers exchange incremental, triggered route updates and periodic keepalives.
Operation – IP EIGRP Neighbor Table
– IP EIGRP Topology Table AD+FD
– The IP Routing Table
Neighbor Table
Topology Table LSDB
Routing Table
(LSA-> LSDB-> SPF algorithm-> SPF Tree-> Routing Table)
 
Function is controlled by EIGRP’s function is controlled by 4 key technologies:
– Neighbor discovery and maintenance: Periodic hello messages
– The Reliable Transport Protocol (RTP): Controls sending, tracking, and acknowledging EIGRP messages
– Diffusing Update Algorithm (DUAL): Determines the best loop-free route
– Protocol-independent modules (PDM): Modules are “plug-ins” for IP, IPX, Novel Netware and AppleTalk versions of EIGRP
Following are several types of areas:
– Backbone area: Area 0, which is attached to every other area.
– Regular area: Nonbackbone area; its database contains both internal and external routes.
– Stub area: It’s database contains only internal routes and a default route.
– Totally Stubby Area: Cisco proprietary area designation. Its database contains routes only for its own area and a
default route.
– Not-so-stubby area (NSSA): Its database contains internal routes, routes redistributed from a connected routing
process, and optionally a default route.
– Totally NSSA: Cisco proprietary area designation. Its database contains only routes for its own area, routes redistributed
from a connected routing process, and a default route.
BGP uses 3 databases. The first two listed are BGP-specific; the third is shared by all routing processes on the router:
– Neighbor database: A list of all configured BGP neighbors. To view it, use the show ip bgp summary
command.
– BGP database, or RIB (Routing Information Base): A list of networks known by BGP, along with their
paths and attributes. To view it, use the show ip bgp command.
– Routing table: A list of the paths to each network used by the router, and the next hop for each network. To view
it, use the show ip route command.
Packet Types/BGP Message Types EIGRP uses 5 packet types:
Hello: Identifies neighbors and serves as a keepalive mechanism sent multicast
Update: Reliably sends route information unicast to a specific router
Query: Reliably requests specific route information query packet multicast to its neighbors
Reply: Reliably responds to a query replies are unicast
ACK: Acknowledgment
The 5 OSPF packet types follow:
Hello: Identifies neighbors and serves as a keepalive.
Link State Request (LSR): Request for a Link State Update (LSU). Contains the type of LSU requested and the
ID of the router requesting it.
Database Description (DBD): A summary of the LSDB, including the RID and sequence number of each LSA
in the LSDB.
Link State Update (LSU): Contains a full LSA entry. An LSA includes topology information; for example, the
RID of this router and the RID and cost to each neighbor. One LSU can contain multiple LSAs.
Link State Acknowledgment (LSAck): Acknowledges all other OSPF packets (except Hellos).
BGP has 4 types of messages:
Open: After a neighbor is configured, BGP sends an open message to try to establish peering with that neighbor.
Includes information such as autonomous system number, router ID, and hold time.
Update: Message used to transfer routing information between peers. Includes new routes, withdrawn routes, and
path attributes.
Keepalive: BGP peers exchange keepalive messages every 60 seconds by default. These keep the peering session
active.
Notification: When a problem occurs that causes a router to end the BGP peering session, a notification message
is sent to the BGP neighbor and the connection is closed.
Neighbor Discovery and Route Exchange Neighbor Discovery and Route Exchange
Step 1. Router A sends out a hello.
Step 2. Router B sends back a hello and an update. The update contains routing information.
Step 3. Router A acknowledges the update.
Step 4. Router A sends its update.
Step 5. Router B acknowledges.
Establishing Neighbors and Exchanging Routes
Step 1. Down state: OSPF process not yet started, so no Hellos sent.
Step 2. Init state: Router sends Hello packets out all OSPF interfaces.
Step 3. Two-way state: Router receives a Hello from another router that contains its own router ID in the neighbor
list. All other required elements match, so routers can become neighbors.
Step 4. Exstart state: If routers become adjacent (exchange routes), they determine which one starts the
exchange process.
Step 5. Exchange state: Routers exchange DBDs listing the LSAs in their LSD by RID and sequence number.
Step 6. Loading state: Each router compares the DBD received to the contents of its LS database. It then sends a
LSR for missing or outdated LSAs. Each router responds to its neighbor’s LSR with a Link State Update.
Each LSU is acknowledged.
Step 7. Full state: The LSDB has been synchronized with the adjacent neighbor.
BGP Peering States
The command show ip bgp neighbors shows a list of peers and the status of their peering session. This status can
include the following states:
Idle: No peering; router is looking for neighbor. Idle (admin) means that the neighbor relationship has been
administratively shut down.
Connect: TCP handshake completed.
OpenSent, or Active: An open message was sent to try to establish the peering.
OpenConfirm: Router has received a reply to the open message.
Established: Routers have a BGP peering session. This is the desired state.
Metric (Calculation) Bandwidth+Delay Cost= 100 Mbps/Bandwidth IBGP – 0
Redistributed routes metric = IGP metric

Reference:
http://cisconetworkingcenter.blogspot.com/2013/01/comparison-of-routing-protocols-eigrp.html

Incoming search terms:

  • what information does rip and ospf protocols send to routers

When a Router receives a BGP UPDATE packet that contains Network Layer Reachability Information (NLRI) – this is, a route; the packet is processed in the next order:

– Step 1. BGP checks for the NLRI (prefix received) against any BGP inbound filter configured on the Router.

– Step 2. If the NLRI is not filtered, the prefix can be seen in the BGP table with the show ip bgp command.

– Step 3. If the Routing Table already has the same prefix/prefix-length entry with a lower Administrative Distance (AD) as seen in show ip route, BGP marks the route received with RIB-Failure.

*You can display BGP routes that are not inserted in the IP routing table with the show ip bgp rib-failure command, which also explains why the BGP route was not inserted in the IP routing table.

*all routes shown in show ip bgp rib-failure command will still advertised to all BGP peers.

*Network Layer Reachability Information (NLRI)

The Network Layer Reachability Information (NLRI) is exchanged between BGP routers using UPDATE messages. An NLRI is composed of a LENGTH and a PREFIX. The length is a network mask in CIDR notation (eg. /25) specifying the number of network bits, and the prefix is the Network address for that subnet.

The NLRI is unique to BGP version 4 and allows BGP to carry supernetting information, as well as perform aggregation.

The NLRI would look something like one of these:

     /25, 204.149.16.128
     /23, 206.134.32
     /8, 10

Reference:
1. https://blog.ipspace.net/2007/12/what-is-bgp-rib-failure.html
2. https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/213286-understand-bgp-rib-failure-and-the-bgp-s.html#anc4
3. https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5816-bgpfaq-5816.html#anc27

Why use /etc/fstab instead of Kodi’s built in NFS client? Using /etc/fstab is faster than Kodi’s own NFS client – it delivers better throughput and is more reliable (also than SMB mounting). Many performance issues, especially with high-bitrate content can be solved by using NFS shares and /etc/fstab. Additionally, it’s quite easy to set up.

Preparation:
You will need to know the following information
1.The IP address of the system where your media files are shared from. (in this tutorial, i will be using 192.168.1.5)
2.The directory used by the NFS share on your NAS. Use the following command to find the correct export path for your NAS

showmount -e IP_of_your_NAS

3. Mount point in OSMC. (in this tutorial, i will be using /mnt/NFS_Share)

Edit your /etc/fstab file:

sudo nano /etc/fstab

Go to the end of the file (use the down arrow key) and add this line:

192.168.1.5:/mnt/array1/share /mnt/NFS_Share    nfs     noauto,x-systemd.automount  0  0

Once done editing /etc/fstab, save the file and exit nano /etc/fstab with CTRL+X and Y for “yes”.

Now verify that there are no errors in your fstab file:

sudo mount -a

Once you get a prompt with no errors, you will need to reload systemd:

sudo systemctl daemon-reload
sudo systemctl restart remote-fs.target

At this point, your shares should just work. To test, simply try to go to the share:

cd /mnt/NFS_Share 
ls

Source: https://discourse.osmc.tv/t/configuring-fstab-based-nfs-share-mounts/69953

The BGP aggregate-address can be used to summarise a set of networks into a single prefix. For this post, I just wanted to show the difference between aggregate-address and aggregate-address with summary only.

We have below topology. I’m going to summarise prefixes in R1.

R1 config

hostname R1
!
interface GigabitEthernet0/0
 ip address 10.10.10.1 255.255.255.252
!
router bgp 10
 bgp log-neighbor-changes
 network 192.168.1.0
 network 192.168.2.0
 network 192.168.3.0
 neighbor 10.10.10.2 remote-as 20
!
ip route 192.168.1.0 255.255.255.0 Null0
ip route 192.168.2.0 255.255.255.0 Null0
ip route 192.168.3.0 255.255.255.0 Null0
!

R2 config

hostname R2
!
interface GigabitEthernet0/0
 ip address 10.10.10.2 255.255.255.252
!
router bgp 20
 bgp log-neighbor-changes
 neighbor 10.10.10.1 remote-as 10
!

Case 1: without aggregate-address

R2#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.10.10.1               0             0 10 i
 *>  192.168.2.0      10.10.10.1               0             0 10 i
 *>  192.168.3.0      10.10.10.1               0             0 10 i

Case 2: with aggregate-address
R1 config

router bgp 10
 bgp log-neighbor-changes
 network 192.168.1.0
 network 192.168.2.0
 network 192.168.3.0
 aggregate-address 192.168.0.0 255.255.252.0
Router#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.0.0/22   10.10.10.1               0             0 10 i
 *>  192.168.1.0      10.10.10.1               0             0 10 i
 *>  192.168.2.0      10.10.10.1               0             0 10 i
 *>  192.168.3.0      10.10.10.1               0             0 10 i

Note that we will be having the original /24 routes (longer prefix) and summarised /22 route.

Case 3: aggregate-address with summary only
R1 config

router bgp 10
 bgp log-neighbor-changes
 network 192.168.1.0
 network 192.168.2.0
 network 192.168.3.0
 aggregate-address 192.168.0.0 255.255.252.0 summary-only
R2#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.0.0/22   10.10.10.1               0             0 10 i

All the longer-prefixes inside of the aggregate address are suppressed.

1. Make sure the telnet in Administration > System tab > Telnet is enabled. Or SSH enabled if you prefer SSH.
2. Telnet to your router using Putty tool, login. Make sure putty is tick Telnet. If SSH then SSH ticked.

3. Type in command “nvram show | grep asus_device_list
You will see something similar to this, below AC68U is my wifi SSID, same goes to MAC and router IP.
Make sure you copy yours, not mine. lol

Sample result:
asus_device_list=<3>TENDA>192.168.1.1>D8:65:63:D4:3D:40>0>AC68U>255.255.255.0>1

4. Copy the entire string above except “asus_device_list=” and also replace “TENDA” to “RT-AC68U

Command: nvram set asus_device_list=”< paste the string starting from <3> until 255.255.255.0>1 >”

Sample:
nvram set asus_device_list=”<3>TENDA>192.168.1.1>D8:65:63:D4:3D:40>0>AC68U>255.255.255.0>1″

5. Type in command “nvram show | grep asus_device_list” again to check whether it has the latest changes you made.

6. Next, type in “nvram show | grep odmpid”
You will see it’s showing TENDA

7. Type in nvram set odmpid=RT-AC68U (For this part, after commit & reboot, if you issue “nvram show | grep odmpid” again it will be empty, but it still works. Need other sifu to comment on this part)

8. Type in “nvram show | grep odmpid” to check again.

9. Check your setting with this command, nvram show | grep RT-AC68U
computer_name=RT-AC68U

odmpid=RT-AC68U
asus_device_list=<3>RT-AC68U>192.168.1.1>D8:65:63:D4:3D:40>0>AC68U>255.255.255.0>1

10. Type in nvram commit to to apply.

11. Type in “reboot” and router will reboot. 

12. Download ASUS router app to try

source: https://forum.lowyat.net/index.php?showtopic=4504268&view=findpost&p=90503295

Incoming search terms:

  • asuswrt tenda ac18
  • ac18 华硕app
  • amount6v3
  • cardc7z
  • hotfbl
  • tenda ac 18 asus c68u
  • tenda ac18 merlin
  • vaporuaa
  • worthb8b

Objectives

We are going to achieve 2 things here.
1. Install the OpenVZ OS
2. Install Ruby 1.8
3. Install the OpenVZ Web Panel

Install the OpenVZ OS

1. Get the ISO from https://download.openvz.org/virtuozzo/releases/7.0/x86_64/iso/
2. Install it as usual

Install Ruby 1.8

[[email protected]]#command curl -sSL https://rvm.io/mpapis.asc | gpg2 --import -
[[email protected]]#\curl -sSL https://get.rvm.io | bash -s stable

Logout or restart ssh session

[[email protected]]#rvm install 1.8.7

Install the OpenVZ Web Panel

1. SSH to OpenVZ
2. Download OpenVZ Web Panel from github then unzip it

[[email protected] ~]# wget https://github.com/sibprogrammer/owp/archive/master.zip
[[email protected] ~]# unzip master.zip

3. Install the script and ruby dependencies

[[email protected] ~]# cd owp-master/installer/
[[email protected] installer]# chmod 777 ai.sh
[[email protected] installer]# ./ai.sh

4. Access the Web Panel
http://ip:3000
login with admin/admin

Incoming search terms:

  • HTTP/1 1 404 NOT FOUND! Check flash:/s3p01_00 web please