DEV Community: febryandana

OpenVPN with FreeRADIUS User Auth

febryandana — Sat, 06 Aug 2022 05:04:29 +0000

Overview

OpenVPN can utilize RADIUS services as a source of authentication for its user accounts. In this article we will try to integrate OpenVPN with FreeRADIUS and utilize DaloRADIUS for the FreeRADIUS GUI dashboard service. That way, administrators can easily manage OpenVPN users in one place.

1. FreeRADIUS & DaloRADIUS Configuration

FreeRADIUS

1) Install Web Server



sudo -i
apt update && apt -y upgrade
apt -y install apache2
apt -y install php libapache2-mod-php php-{gd,common,mail,mail-mime,mysql,pear,db,mbstring,xml,curl}
php -v

2) Install DB server



apt -y install mariadb-server
mysql_secure_installation

3) Create RADIUS database



mysql -u root -p

MariaDB [(none)]> CREATE DATABASE radius;
MariaDB [(none)]> GRANT ALL ON radius.* TO radius@localhost IDENTIFIED BY "StrongPassword";
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> QUIT

4) Install & Configure FreeRADIUS



apt -y install freeradius freeradius-mysql freeradius-utils

Import freeRADIUS sql database



mysql -u root -p radius < /etc/freeradius/3.0/mods-config/sql/main/mysql/schema.sql
mysql -u root -p -e "use radius; show tables;"

Create softlink to enable sql mod



ln -s /etc/freeradius/3.0/mods-available/sql /etc/freeradius/3.0/mods-enabled/

Configure sql module

Comment SSL sections in mysql



nano /etc/freeradius/3.0/mods-enabled/sql

---
sql {
driver = "rlm_sql_mysql"
dialect = "mysql"

# Connection info:
server = "localhost"
port = 3306
login = "radius"
password = "StrongPassword"

# Database table configuration for everything except Oracle
radius_db = "radius"
}

# Set to ‘yes’ to read radius clients from the database (‘nas’ table)
# Clients will ONLY be read on server startup.
read_clients = yes

# Table to keep radius client info
client_table = "nas"
---

Change Group



chgrp -h freerad /etc/freeradius/3.0/mods-available/sql
chown -R freerad:freerad /etc/freeradius/3.0/mods-enabled/sql

Restart freeradius service



sudo systemctl restart freeradius.service

DaloRADIUS

1) Install daloRadius



apt -y install wget unzip
wget https://github.com/lirantal/daloradius/archive/master.zip
unzip master.zip
mv daloradius-master daloradius
cd daloradius

2) Configure daloRadius

Import daloRadius tables



mysql -u root -p radius < contrib/db/fr2-mysql-daloradius-and-freeradius.sql
mysql -u root -p radius < contrib/db/mysql-daloradius.sql

Move daloRadius folder to Web Server



cd ..
mv daloradius /var/www/html/
mv /var/www/html/daloradius/library/daloradius.conf.php.sample /var/www/html/daloradius/library/daloradius.conf.php
chown -R www-data:www-data /var/www/html/daloradius/
chmod 664 /var/www/html/daloradius/library/daloradius.conf.php

Configure daloRadius connection



nano /var/www/html/daloradius/library/daloradius.conf.php

---
$configValues['CONFIG_DB_HOST'] = 'localhost';
$configValues['CONFIG_DB_PORT'] = '3306';
$configValues['CONFIG_DB_USER'] = 'radius';
$configValues['CONFIG_DB_PASS'] = 'StrongPassword';
$configValues['CONFIG_DB_NAME'] = 'radius';
---

touch /tmp/daloradius.log

Restart services



systemctl restart freeradius.service apache2.service

3) Verify daloRadius

Access via http://IP_ADDRESS/daloradius/login.php



Default User & Password:
User = administrator
Password = radius

2. OpenVPN Installation

OpenVPN

We will install OpenVPN by easy way using automation shell script



apt install -y openvpn openvpn-auth-radius freeradius-utils
wget https://git.io/vpn -O openvpn-install.sh
bash openvpn-install.sh

---
Public IPv4 address / hostname [a.b.c.d]: IP_Server_OpenVPN
---

Change the settings whatever you like

OpenVPN RADIUS Plugin

To connect OpenVPN with FreeRADIUS, we need to use external plugin named radiusplugin



apt update
apt install openvpn-auth-radius

Binary file will be downloaded to /usr/lib/openvpn/radiusplugin.so

3. Integrate OpenVPN with FreeRADIUS

FreeRadius Side

1) Create NAS (Network Access Server) for OpenVPN server

Via DaloRadius:
- NAS IP/Host = 192.168.1.12/24 //IP ADDRESS OPENVPN SERVER
- NAS Secret = fb-ovpn
- NAS Type = other
- NA Shortname = fb-ovpn

Via clients.conf:

```bash

nano clients.conf

---
client fb-ovpn {
    ipaddr = 192.168.1.12 //IP ADDRESS OPENVPN SERVER
    netmask = 24
    secret = fb-ovpn
    shortname = fb-ovpn
    nastype = other
}
---


Restart freeradius service everytime you need to create new NAS

```bash


systemctl restart freeradius.service

OpenVPN Server Side

1) Create cnf file for connecting OpenVPN to FreeRADIUS



nano /etc/openvpn/radiusplugin.cnf

---
NAS-Identifier=openvpn
Service-Type=5
Framed-Protocol=1
NAS-Port-Type=5
NAS-IP-Address=192.168.1.12
OpenVPNConfig=/etc/openvpn/server/server.conf
overwriteccfiles=true
server
{
acctport=1813
authport=1812
name=192.168.1.11
        retry=1
        wait=1
        sharedsecret=fb-ovpn
}
---

2) Test connection to RADIUS via server OpenVPN. You need to create user first from DaloRADIUS



radtest {username} {password} {radius_hostname} 10 {radius_secret}

radtest febry febry 192.168.1.11 10 fb-ovpn

3) Configure file server.conf on OpenVPN server so that OpenVPN will use users from FreeRADIUS server



nano /etc/openvpn/server/server.conf

---
plugin /usr/lib/openvpn/radiusplugin.so /etc/openvpn/radiusplugin.cnf
verify-client-cert
key-direction 0
duplicate-cn
local 192.168.1.12
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify
---

4) Create ovpn file for clients



nano /root/client.ovpn

---
key-direction 1
auth-user-pass
;user nobody
;group nogroup

client
dev tun
proto udp
remote 192.168.1.12 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
<ca>
...
---

4. Test connection to OpenVPN with RADIUS user

Conducted on node fb-ubuntu (192.168.2.11 - lab6)



openvpn --config client.ovpn

Conducted on personal computer



sudo openvpn --config client.ovpn

Known Issues

1) Unknown column 'acctupdatetime' in 'field list'



DaloRadius, RADIUS log :
ERROR: (21) sql: ERROR: rlm_sql_mysql: ERROR 1054 (Unknown column 'acctupdatetime' in 'field list'): 42S22

Solve: Rebuild table radacct



mysql -u root -p radius

DROP TABLE radacct;

CREATE TABLE radacct (
radacctid bigint(21) NOT NULL auto_increment,
acctsessionid varchar(64) NOT NULL default '',
acctuniqueid varchar(32) NOT NULL default '',
username varchar(64) NOT NULL default '',
groupname varchar(64) NOT NULL default '',
realm varchar(64) default '',
nasipaddress varchar(15) NOT NULL default '',
nasportid varchar(15) default NULL,
nasporttype varchar(32) default NULL,
acctstarttime datetime NULL default NULL,
acctupdatetime datetime NULL default NULL,
acctstoptime datetime NULL default NULL,
acctinterval int(12) default NULL,
acctsessiontime int(12) unsigned default NULL,
acctauthentic varchar(32) default NULL,
connectinfo_start varchar(50) default NULL,
connectinfo_stop varchar(50) default NULL,
acctinputoctets bigint(20) default NULL,
acctoutputoctets bigint(20) default NULL,
calledstationid varchar(50) NOT NULL default '',
callingstationid varchar(50) NOT NULL default '',
acctterminatecause varchar(32) NOT NULL default '',
servicetype varchar(32) default NULL,
framedprotocol varchar(32) default NULL,
framedipv6address varchar(32) default NULL,
framedipv6prefix varchar(32) default NULL,
framedinterfaceid varchar(32) default NULL,
delegatedipv6prefix varchar(32) default NULL,
framedipaddress varchar(15) NOT NULL default '',
PRIMARY KEY (radacctid),
UNIQUE KEY acctuniqueid (acctuniqueid),
KEY username (username),
KEY framedipaddress (framedipaddress),
KEY acctsessionid (acctsessionid),
KEY acctsessiontime (acctsessiontime),
KEY acctstarttime (acctstarttime),
KEY acctinterval (acctinterval),
KEY acctstoptime (acctstoptime),
KEY nasipaddress (nasipaddress)
) ENGINE = INNODB;

2) Error reading log file: /tmp/daloradius.log



error reading log file: /tmp/daloradius.log
looked for log file in /tmp/daloradius.log but couldn't find it.
if you know where your daloradius log file is located, set it's location in your library/daloradius.conf file

Solve: Create new log file



touch /tmp/daloradius.log
chown www-data:www-data daloradius.log
chmod 644 /tmp/daloradius.log

3) Error reading log file: /var/log/syslog



error reading log file: /var/log/syslog
possible cause is file permissions or file does not exist.

Solve: Change file permission



chmod 644 /var/log/syslog

4) RADIUS user authentication's type that is compatible with OpenVPN

[x] cleartext-password
[ ] User-password (AUTH_FAILED)
[x] Crypt-password
[x] MD5-password
[ ] SHA1-password (AUTH_FAILED)
[ ] CHAP-password (AUTH_FAILED)

5) Some OS's dont have nogroup user & group but they use nobody, and vice versa. To solve issue with these groups, we can:

Create user nobody and group nogroup.
Cretae user nobody and group nobody. Then edit group nogroup to group nobody in client.ovpn file.
Comment out user nobody and group nogroup in client.ovpn file.

References

Dekatanah

febryandana — Sun, 17 Apr 2022 05:29:31 +0000

A microcontroller-based soil fertility detection system.

Abstract

Soil is the most used plant growth medium. However, due to various soil conditions, not all plants are also suitable for the particular soil to be used, so a tool or sensor is needed that can read and measure soil fertility. Simple soil fertility measurement can be measured from 2 elements of soil fertility attributes, namely the soil pH element and the soil moisture element. Most of the available soil fertility detection instruments or systems only use one of the soil fertility elements and the data on the detection results can't be stored for a long period, making the readings less effective. From these problems, we conducted research to build a soil fertility detection system that uses a soil pH sensor and a soil moisture sensor that is connected to the Arduino Nano microcontroller and can be run with an application on a smartphone. The results of this study are in the form of a soil fertility detection tool and system that can read soil pH and soil moisture content and an Android smartphone application that is connected to the device via the USB-OTG feature. With this application, a test location is obtained where the soil is tested and then stored in the TinyDB database in the application so that data will not be lost even if the tool is turned off.

Keywords: soil, fertility, pH sensor, moisture sensor, microcontroller, Android application

Hardware Specifications

1. Arduino Nano microcontroller

2. Soil pH meter sensor

3. Capacitive soil moisture sensor

4. LED lamp indicator

5. Active Buzzer

6. Voltage Regulator

7. Switch/Push button

8. Diode

9. Jumper cable

10. USB-OTG Adapter

11. Micro USB / Type C USB cable (depends on smartphone USB port)

12. Printed Circuit Board

13. Case

14. Smartphone with support for USB On-The-Go, GPS, and Location Sensor

System Design

System Block Diagram

Hardware Schematic

Hardware System Flowchart

Android App Main Program Flowchart

Android App Sub Program Flowchart

Serial communication

Clock

Location sensor

Show map marker

Save data

Delete data

Save data list

Prototype Implementation

Hardware prototype

PCB design

Final prototype

Prototype on use

Arduino Program

Android Application Program

This Android application uses Kodular Blocks, read more: https://docs.kodular.io/

The full image of these blocks can be seen on: kodular-blocks/kodular-blocks.png.

Main program initialization

0pen serial connection

Read serial data

Get location

Address input

Show location map

Save data and list

Delete data

Android Application User Interface

End Notes

This is a simple college project for Praktik Kerja Lapangan which is supervised by a lecturer. There is still much room for improvement.

Auto Scale Jitsi Meet Server Dengan AWS Autoscaling

febryandana — Sun, 31 Oct 2021 04:06:44 +0000

Pada artikel ini, kita akan belajar membuat autoscaling untuk Jitsi Videobridge, komponen XMPP server Jitsi yang bertanggung jawab untuk pembuatan multiuser video communication. Kita bisa menganggapnya sebagai backend dari Jitsi Meet Server yang bertugas untuk mengurus masalah video & audio di conference room.

Langkah terbaik untuk membuat Jitsi Meet Server adalah dengan memisahkan antara Jitsi Meet, Jibri, dan Jitsi Videobridge ke dalam instance masing". Lebih baik lagi jika kita membuat autoscaling untuk videobridge (dan juga Jibri, tapi kita akan fokus pada videobridge saja sekarang), dengan begitu, resource yang perlu digunakan dapat menyesuaikan dengan kebutuhan, tidak ada yang menganggur atau kelebihan beban. Langkah-langkah pembuatan autoscaling untuk Jitsi Videobridge menggunakan Amazon Web Service adalah sebagai berikut.

Persiapan Instance

Pertama kita perlu membuat instance baru yang akan menjadi template dari Jitsi Videobridge. Cara pembuatan instance bisa dilihat di artikel Membuat EC2 di AWS. Port yang perlu dibuka di Security Group adalah port 22/TCP, 10000/UDP, 5347/TCP, dan 4443/TCP.

Instalasi Jitsi Videobridge

Setelah instance terbuat dan kita bisa masuk ke dalam instance, selanjutnya kita perlu menambahkan repository dari Jitsi dan memasang paket instalasi jitsi-videobridge2.

# Install dependencies
sudo apt install -y apt-transport-https

# Adding jitsi repository
echo 'deb https://download.jitsi.org stable/' | sudo tee \ /etc/apt/sources.list.d/jitsi-stable.list
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -

# Update system
sudo apt-get update

# Install jitsi-videobridge2
sudo apt install -y jitsi-videobridge2

Konfigurasi Jitsi Videobridge

Tahap selanjutnya adalah melakukan sedikit tweaking pada Jitsi Meet Server dan beberapa file konfigurasi jitsi-videobridge agar dapat digunakan untuk autoscaling.

Yang pertama adalah menambahkan user baru khusus untuk videobridge melalui komponen prosodyctl pada instance Jitsi Meet Server. User ini akan digunakan sebagai autentikasi saat ada videobridge baru yang tersambung.

sudo prosodyctl register jvb auth.meet.yourdomain.com yourjvbpassword

Selanjutnya adalah file sip-communicator.properties yang ada di instance jitsi-videobridge. File ini digunakan untuk memberitahu videbridge tentang informasi-informasi dirinya sendiri dan Jitsi Meet Server yang akan dihubungi.

sudo nano /etc/jitsi/videobridge/sip-communicator.properties

Konten file sip-communicator.properties :

org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true
org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=meet.yourdomain.com
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.meet.yourdomain.com
org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=yourjvbpassword
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=jvbbrewery@internal.auth.meet.yourdomain.com
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=1cc60513-7064-4c47-afee-a838eb29a58c
org.jitsi.videobridge.DISABLE_TCP_HARVESTER=false
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_SSLTCP=true
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=172.0.0.1
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=11.22.33.44

Berikutnya adalah file jvb.conf dan file config yang berisi konfigurasi dasar dari jitsi-videobridge.

sudo nano /etc/jitsi/videobridge/jvb.conf

Konten file jvb.conf :

videobridge {
 http-servers {
  public {
   port = 9090
  }
 }
 websockets {
  enabled = true
  domain = "meet.yourdomain.com:443"
  tls = true
 }
}

sudo nano /etc/jitsi/videobridge/config

Konten file config :

# Jitsi Videobridge settings

# sets the XMPP domain (default: none)
JVB_HOSTNAME=localhost

# sets the hostname of the XMPP server (default: domain if set, localhost otherwise)
JVB_HOST=

# sets the port of the XMPP server (default: 5275)
JVB_PORT=5347

# sets the shared secret used to authenticate to the XMPP server
JVB_SECRET=jvbpassword

# extra options to pass to the JVB daemon
JVB_OPTS="--apis=,"

Yang terakhir adalah konfigurasi file jvb.sh yang akan dijalankan saat jitsi-videobridge pertama kali aktif (pertama kali booting). Buka file jvb.sh dan tambahkan baris berikut di bagian atas file.

sudo nano /usr/share/jitsi-videobridge/jvb.sh

Konten file jvb.sh :

RAND=`openssl rand -hex 5`
USERNAME=jvb
BRIDGE=bridge$RAND
JVB_SECRET=yourjvbpassword
NICKNAME=`uuidgen`
LOCAL_ADDRESS=`hostname -I | awk '{print $1}'`
PUBLIC_ADDRESS=`curl ifconfig.me`
sed -i "s/\(JVB_SECRET=\).*\$/\1${JVB_SECRET}/" /etc/jitsi/videobridge/config
sed -i "s/\(org.jitsi.videobridge.xmpp.user.shard.USERNAME=\).*\$/\1${USERNAME}/" /etc/jitsi/videobridge/sip-communicator.properties
sed -i "s/\(org.jitsi.videobridge.xmpp.user.shard.PASSWORD=\).*\$/\1${JVB_SECRET}/" /etc/jitsi/videobridge/sip-communicator.properties
sed -i "s/\(org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=\).*\$/\1${NICKNAME}/" /etc/jitsi/videobridge/sip-communicator.properties
sed -i "s/\(org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=\).*\$/\1${LOCAL_ADDRESS}/" /etc/jitsi/videobridge/sip-communicator.properties
sed -i "s/\(org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=\).*\$/\1${PUBLIC_ADDRESS}/" /etc/jitsi/videobridge/sip-communicator.properties
sed -i "s/\(org.jitsi.videobridge.octo.BIND_ADDRESS=\).*\$/\1${LOCAL_ADDRESS}/" /etc/jitsi/videobridge/sip-communicator.properties
sed -i "s/\(org.jitsi.videobridge.octo.PUBLIC_ADDRESS=\).*\$/\1${PUBLIC_ADDRESS}/" /etc/jitsi/videobridge/sip-communicator.properties
sed -i "s/\(org.jitsi.videobridge.REGION=\).*\$/\1${BRIDGE}/" /etc/jitsi/videobridge/sip-communicator.properties

Setelah selesai, kita bisa melakukan test dengan restart service jitsi-videobridge2 dan sekaligus mengaktifkan autostart agar service tersebut selalu dijalankan setiap sistem aktif.

sudo systemctl enable jitsi-videobridge2
sudo systemctl restart jitsi-videobridge2

Sampai sini, tahap pembuatan instance untuk jitsi-videobridge2 telah selesai. Selanjutnya kita bisa memanfaatkan instance tersebut untuk membuat template baru untuk autoscaling.

Pembuatan Template

Untuk membuat instance template, pertama kita perlu mematikan instance dengan klik Instance state -> Stop instance. Selanjutnya kita buat template dengan klik Action -> Image and templates -> Create template from instance.

Beri nama dan deskripsi untuk template yang akan dibuat. Lalu centang checkbox Provide guidance to help me set up a template that I can use with EC2 Auto Scaling untuk mendapat bantuan konfigurasi template yang sesuai untuk autoscaling.

Pada bagian Network Interfaces, untuk pengaturan subnet, pilih Specify custom value... dan klik Save tanpa memberikan value.

Kemudian klik Advanced Details untuk membuka pengaturan lanjutan. Pada bagian Shutdown behavior dan Stop - Hibernate behavior, pilih opsi Don't include in launch template. Setelah pengaturan sudah cukup dan tidak ada tanda merah, klik Create launch template untuk mengonfirmasi pembuatan template.

Pembuatan Auto Scaling Group

Tahap terakhir adalah pembuatan auto scaling group. Menu auto scaling group bisa dibuka dari EC2 Services. Buka EC2 dari menu All Services atau melalui Search Bar, lalu pilih opsi Auto Scaling Group dari kolom sebelah kiri, kemudian klik Create Auto Scaling Group.

Berikut adalah tampilan wizard dari Create Auto Scaling Group. AWS telah memudahkan pembuatan auto scaling group dengan menyediakan urutan langkah-langkah pembuatan. Kita cukup mengikutinya dan mengisikan data-data yang perlu diatur.

Pertama kita perlu memberi nama group dan memilih launch template yang telah kita buat sebelumnya. Pemilihan nama harus unik dalam satu akun di Region tersebut, dan tidak boleh lebih dari 255 karakter. Setelah selesai memberi nama dan launch template, klik Next untuk melanjutkan.

Pada langkah kedua, Pada bagian Instance purchase options, kita dapat mengatur berapa persen yang akan dibayar secara on-demand dan secara spot instances. Selanjutnya pada bagian Network, kita dapat mengatur VPC yang akan digunakan beserta Availability Zone dan Subnet yang akan digunakan oleh instances dalam auto scaling group. Kemudian pada bagian Instance type requirements kita bisa memilih untuk menggunakan instance type sesuai dengan template yang sudah dibuat atau mengubahnya ke instance type yang lain. Setelah selesai, klik Next untuk melanjutkan.

Untuk langkah ke-3 hingga step ke-6 sifatnya adalah optional. Langkah ketiga berisi opsi untuk memasangkan auto scaling group ke load balancer, health check, dan monitoring melalui CloudWatch.

Langkah ke-4 berisi opsi Group size untuk mengatur ukuran group (kapasitas instance yang diinginkan, kapasitas minimal, dan kapasitas maksimal). Scaling policies untuk mengatur bagaimana grup akan melakukan scaling, berupa Target tracking dari Average CPU Utilization, Average Network In/Out, dan jumlah request dari Application Load Balancer. Opsi Instance scale-in protection digunakan untuk memproteksi instance yang terbuat dari aksi scale-in (mengurangi/menghapus instance yang tak terpakai).

Langkah ke-5 berisi opsi untuk memberikan notifikasi jika ada event yang terjadi pada auto scaling group. Kita bisa mengirimkan topik SNS ke administrator jika ada event berupa : launch instance, terminate instance, Instance fail to launch, dan instance fail to terminate.

Langkah ke-6 berisi opsi penambahan tag berupa key-value untuk auto scaling group.

Langkah terakhir berupa review dari kumpulan konfigurasi yang telah kita buat di langkah-langkah sebelumnya. Disini kita bisa mengecek apabila ada pengaturan yang salah atau terlewatkan. Jika dirasa sudah cukup, kita bisa mengonfirmasi pembuatan auto scaling group dengan klik tombol Create Auto Scaling Group.

Gambar di atas adalah tampilan Auto Scaling Group yang telah kita buat. Kita bisa melihat informasi detail tentang auto scaling group tersebut dengan klik tanda centang dan memperhatikan daftar kolom di bawahnya, atau langsung klik nama group tersebut. Sampai sini pembuatan auto scaling group Jitsi Videobridge telah selesai dan seharusnya instance baru khusus untuk videobridge telah terbuat dan terhubung dengan Jitsi Meet Server.

Referensi

Amazon EC2 Auto Scaling User Guide. Retrieved September 26, 2021, from https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html
Garcia, A. (2020). Script for Autoscaling JVB. Community.Jitsi.Org. Retrieved September 26, 2021, from https://community.jitsi.org/t/script-for-autoscaling-jvb/59157/11

Auto Uploader File Record Jibri ke Google Drive

febryandana — Sat, 30 Oct 2021 03:25:09 +0000

Setelah Jibri berhasil dipasang, tentunya kita ingin untuk bisa mengakses file-file hasil rekaman tersebut. Secara default, Jibri menyimpan hasil rekamannya di direktori /srv/recordings tanpa ada fitur untuk mengunggahnya ke layanan cloud storage.
Ada banyak cara untuk bisa mengunggah file rekaman ke cloud storage mulai dari sync folder, FTP/File server, memanfaatkan layanan AWS S3 jika server Jibri berada di AWS, atau menggunakan rclone untuk menyambungkan server kita dengan layanan cloud storage lain. Pada artikel ini, kita akan memanfaatkan rclone untuk mengunggah file rekaman Jibri ke layanan Google Drive.

1. Membuat file konfigurasi rclone di host machine

Pada artikel ini, penulis menggunakan PC pribadi sebagai host machine dengan sistem operasi Fedora 34. Kalian bisa menyesuaikan cara instalasi rclone sesuai dengan sistem operasi kalian sendiri.
Paket rclone sudah tersedia di repository Fedora 34 sehingga kita hanya perlu memberi perintah:

sudo dnf upgrade -y
sudo dnf install -y rclone

Setelah proses instalasi selesai, kita lanjutkan dengan proses membuat file konfigurasi, prosesnya adalah sebagai berikut:

rclone config

Cara konfigurasi rclone untuk Google Drive bisa kalian baca langsung disini.

2. Mengirimkan file konfigurasi tersebut ke server Jibri

Di server Jibri, kita juga perlu memasang paket rclone. Karena sebelumnya kita menggunakan Ubuntu Server 18.04 sebagai server Jibri, paket rclone sudah tersedia di repositori:

sudo apt-get install rclone

Untuk mengirimkan file rclone.conf yang sudah dibuat sebelumnya, kita bisa menggunakan layanan scp atau sftp. Misalnya menggunakan scp maka perintahnya adalah:

scp ~/.config/rclone/rclone.conf jibri@IP_PUBLIC_JIBRI_SERVER:/home/jibri/.config/rclone/rclone.conf

Dapat diperhatikan bahwa tujuan pengiriman kita adalah ke home direktori dari user jibri. Ini karena nanti rclone akan dijalankan oleh user jibri melalui file finalize.sh.

Selanjutnya untuk memeriksa apakah config file kita sudah siap, kita bisa menggunakan perintah berikut dari dalam server Jibri:

// Masuk ke user jibri yang akan menjalankan rclone:
su - jibri

// Ubah ownership dari file rclone.conf
sudo chown jibri:jibri /home/jibri/.config/rclone.rclone.conf

// Cek ketersediaan config file:
rclone config file

Jika tidak ada error sampai sini berarti rclone sudah siap digunakan. Kita bisa mengujinya dengan memeriksa daftar file yang ada di Google Drive:

Parameter googledrive: yang digunakan adalah nama config yang kita buat di rclone sebelumnya. Jika Anda membuat config dengan nama yang berbeda, ganti googledrive: sesuai dengan nama config yang Anda miliki.

rclone ls googledrive:

Untuk mengirim file dari server ke Google Drive, menggunakan perintah:

rclone copy /FILE/PATH googledrive:

Untuk mengirim file ke folder tertentu di Google Drive, bisa menggunakan perintah:

rclone copy /FILE/PATH googledrive:FOLDER/PATH/

3. Membuat file finalize.sh untuk menjalankan rclone secara otomatis

Setelah rclone selesai dikonfigurasi, selanjutnya kita perlu menyiapkan file finalize.sh untuk dijalankan Jibri setiap selesai rekaman. Path dari file ini sesuai dengan apa yang sudah kita tentukan di file /etc/jitsi/jibri/jibri.conf. Contohnya pada server Jibri sebelumnya, path file finalize.sh berada di /srv/finalize.sh.
Kita perlu membuat sekaligus membuka file /srv/finalize.sh. Kita bisa menggunakan nano, vim, atau text editor lainnya. Contoh:

sudo nano /srv/finalize.sh

Selanjutnya masukkan baris program di bawah ini ke dalam file finalize.sh:

#!/bin/bash

RECORDINGS_DIR=$1

VIDEO_FILE_PATH=$(find $RECORDINGS_DIR -name *.mp4)

/usr/bin/rclone copy $VIDEO_FILE_PATH googledrive:meet.yourdomain.com/ -v --log-file=/var/log/jitsi/jibri/googledrive_upload.log

Cara kerja program tersebut adalah dengan mengambil path direktori hasil rekaman yang baru saja dilakukan Jibri, kemudian mencari file dengan ekstensi mp4, lalu menyalin file tersebut ke dalam folder meet.yourdomain.com di Google Drive dengan bantuan aplikasi rclone. Opsi -v akan membuat rclone menampilkan output yang lebih banyak & lengkap. Selain itu, dengan opsi --log-file, rclone juga akan menyimpan informasi penggunaan dengan membuat log file di /var/log/jitsi/jibri/googledrive_upload.log.

Setelah selesai, simpan dan keluar dari file finalize.sh. Selanjutnya kita perlu mengatur permission dan ownership dari file tersebut agar dapat dieksekusi oleh Jibri:

sudo chown jibri:jibri /srv/finalize.sh
sudo chmod +x /srv/finalize.sh

Sampai sini fitur auto uploader file rekaman Jibri ke Google Drive telah selesai. Kita bisa mengujinya dengan melakukan rekaman di Jitsi Meet. Setelah selesai, file rekamannya seharusnya diunggah ke folder meet.yourdomain.com di akun Google Drive yang sudah dipilih sebelumnya.
Pemanfaatan rclone tidak berhenti hanya sampai disini saja. Kita juga bisa menggunakan layanan cloud storage atau layanan penyimpanan file lain selain Google Drive untuk mengirim file rekaman Jibri.

Referensi

Menambahkan Jibri Recorder untuk Jitsi Meet Server

febryandana — Fri, 29 Oct 2021 07:14:10 +0000

Setelah menyelesaikan panduan instalasi Jitsi Meet, kita dapat menggunakannya untuk rapat atau pertemuan secara online. Tetapi ada fitur yang tidak ikut terinstall, yaitu fitur rekaman. Fitur ini sangat berguna apabila kita perlu menyimpan hasil konferensi online kita untuk diarsipkan atau di-upload ke Youtube. Untungnya, Jitsi juga menyediakan layanan rekaman dengan nama Jibri. Pada artikel ini, kita akan mencoba melakukan instalasi Jibri untuk Jitsi Meet Sever sebelumnya.

Hal yang perlu diperhatikan sebelum melakukan instalasi Jibri antara lain :

Jibri bekerja dengan membuat sebuah instance browser Chrome untuk masuk ke dalam room Jitsi lalu menangkap dan melakukan proses encoding video dan audion dengan FFMPEG. Oleh karena itu Jibri sebaiknya dipasang pada standalone system yang dibuat khusus untuk Jibri.
Karena melakukan proses encoding video dan audio, Jibri membutuhkan resource yang cukup besar. Spesifikasi yang direkomendasikan adalah 4 core CPU dan 8 GB memory. Jibri juga perlu ruang storage yang cukup besar untuk menyimpan hasil rekamannya.
Saat ini, satu Jibri instance hanya bisa melakukan 1 proses record. Jika ada banyak room dan semuanya perlu untuk merekam maka kita juga harus menyediakan instance Jibri sesuai jumlah room tersebut.
Jibri membutuhkan modul ALSA loopback yang ada di generic kernel. Jika kita menggunakan AWS maka perlu untuk mengubah kernel-nya menjadi kernel generic.

Mengubah kernel AWS menjadi generic-kernel pada Ubuntu Server 18.04 AWS

Pertama-tama kita perlu install image generic-kernel dengan perintah:

sudo apt-get update
sudo apt-get upgrade -y
sudo apt install linux-image-extra-virtual

Cek kernel yang saat ini digunakan dengan perintah:

uname -r

Jika masih ada "aws" berarti Ubuntu Server masih menggunakan kernel AWS.

Cek daftar kernel yang tersedia dengan perintah:

grep -A100 submenu /boot/grub/grub.cfg |grep menuentry

Contoh hasil keluarannya adalah seperti di bawah ini:

submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-db937f23-4ed7-4c4b-8058-b23a860fae08' {
        menuentry 'Ubuntu, with Linux 5.4.0-1054-aws' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-1054-aws-advanced-db937f23-4ed7-4c4b-8058-b23a860fae08' {             menuentry 'Ubuntu, with Linux 5.4.0-1054-aws (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-1054-aws-recovery-db937f23-4ed7-4c4b-8058-b23a860fae08' {
        menuentry 'Ubuntu, with Linux 5.4.0-1045-aws' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-1045-aws-advanced-db937f23-4ed7-4c4b-8058-b23a860fae08' {             menuentry 'Ubuntu, with Linux 5.4.0-1045-aws (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.4.0-1045-aws-recovery-db937f23-4ed7-4c4b-8058-b23a860fae08' {
        menuentry 'Ubuntu, with Linux 4.15.0-153-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-153-generic-advanced-db937f23-4ed7-4c4b-8058-b23a860fae08' {
        menuentry 'Ubuntu, with Linux 4.15.0-153-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-153-generic-recovery-db937f23-4ed7-4c4b-8058-b23a860fae08' {

Salin id option dari baris pertama (Advanced options for Ubuntu). Contohnya seperti di bawah ini:

gnulinux-advanced-db937f23-4ed7-4c4b-8058-b23a860fae08

Selanjutnya salin id option dari bagian generic (Ubuntu, with Linux 4.15.0-153-generic). Contohnya seperti di bawah ini:

gnulinux-4.15.0-153-generic-advanced-db937f23-4ed7-4c4b-8058-b23a860fae08

Kombinasikan keduanya menggunakan tanda > menjadi seperti di bawah ini:

gnulinux-advanced-db937f23-4ed7-4c4b-8058-b23a860fae08>gnulinux-4.15.0-153-generic-advanced-db937f23-4ed7-4c4b-8058-b23a860fae08

Kemudian edit file grub.cfg dengan perintah:

sudo nano /etc/default/grub.cfg

Ubah value dari GRUB_DEFAULT=0 dengan value di atas, menjadi

GRUB_DEFAULT='gnulinux-advanced-db937f23-4ed7-4c4b-8058-b23a860fae08>gnulinux-4.15.0-153-generic-advanced-db937f23-4ed7-4c4b-8058-b23a860fae08'

Simpan dan keluar, lalu restart grub dan sistem:

sudo update-grub && sudo update-grub2
sudo restart

Kemudian cek apakah kernel telah berubah dengan perintah uname -r. Seharusnya hasilnya menjadi:

$ uname -r
4.15.0-153-generic

Persiapan di Jitsi Meet Server Instance

Semua domain yang digunakan pada panduan ini adalah meet.yourdomain.com. Kalian perlu mengubahnya ke domain Jitsi kalian sendiri. Pertama-tama kita perlu menyiapkan environment Jibri pada Jitsi Meet Server, antara lain:

Prosody

Kita perlu membuat entry untuk internal muc agar Jibri client dapat berkomunikasi dengan Jicofo. Edit file /etc/prosody/conf.avail/meet.yourdomain.com.cfg.lua, cari dan sesuaikan dengan baris berikut:

-- internal muc component, meant to enable pools of jibri and jigasi clients
Component "internal.auth.meet.yourdomain.com" "muc"
    modules_enabled = {
      "ping";
    }
    -- storage should be "none" for prosody 0.10 and "memory" for prosody 0.11
    storage = "memory"
    admins = { "focus@auth.meet.yourdomain.com", "jvb@auth.meet.yourdomain.com", "jibri@auth.meet.yourdomain.com" }
    muc_room_locking = false
    muc_room_default_public_jids = true
    muc_room_cache_size = 1000
    c2s_require_encryption = false

Selanjutnya kita perlu membuat virtual host entry untuk recorder untuk sebagai user akun untuk sesi Jibri. Hal ini diperlukan agar Jibri dapat menjadi hidden participant pada konferensi yang direkam. Edit dan tambahkan baris berikut ke file /etc/prosody/conf.avail/meet.yourdomain.com.cfg.lua:

VirtualHost "recorder.meet.yourdomain.com"
  modules_enabled = {
    "ping";
  }
  authentication = "internal_plain"
  c2s_require_encryption = false
  allow_empty_token = true

Kemudian kita perlu membuat akun untuk Jibri dengan perintah:

sudo prosodyctl register jibri auth.meet.yourdomain.com jibriauthpass
sudo prosodyctl register recorder recorder.meet.yourdomain.com jibrirecorderpass

Simpan username dan password dari prosodyctl di atas karena nantinya akan diperlukan lagi.

Jicofo

Edit file /etc/jitsi/jicofo/sip-communicator.properties dan tambahkan baris berikut ini:

org.jitsi.jicofo.jibri.BREWERY=JibriBrewery@internal.auth.meet.yourdomain.com
org.jitsi.jicofo.jibri.PENDING_TIMEOUT=90

Baris tersebut diperlukan untuk membuat MUC yang sesuai untuk Jibri Controllers agar dapat berkomunikasi dengan Jicofo. PENDING_TIMEOUT juga sebaiknya di-set ke 90 detik untuk memberikan jeda waktu Jibri sebelum dicap failed dan dimatikan.

Jitsi Meet

Edit file /etc/jitsi/meet/meet.yourdomain.com-config.js lalu cari dan tambahkan set konfigurasi berikut ini:

fileRecordingsEnabled: true, // Untuk mengaktifkan fitur file recording
liveStreamingEnabled: true, // Untuk mengaktifkan fitur live streaming
hiddenDomain: 'recorder.meet.yourdomain.com', // Untuk menyembunyikan user jibri dari room

Proses Instalasi Jibri di Jibri Instance

Panduan selanjutnya dilakukan di instance Jibri. Pertama-tama pastikan modul ALSA loopback telah tersedia dengan mengikuti panduan mengubah kernel AWS menjadi kernel generic di awal.

ALSA dan Loopback Device

Jalankan beberapa perintah di bawah ini untuk mengaktifkan modul ALSA loopback

Set modul agar di-load saat boot : sudo echo "snd-aloop" >> /etc/modules
Load modul ke kernel saat ini : sudo modprobe snd-aloop
Cek jika modul telah di-load : sudo lsmod | grep snd_aloop
Jika output-nya menampilkan modul snd-aloop, berati ALSA loopback telah selesai dikonfigurasi.

Google Chrome dan Chromedriver

Selanjutnya kita perlu memasang Google Chrome stabil dan Chromedriver yang akan digunakan Jibri untuk mengakses room Jitsi dan melakukan rekaman. Instruksi instalasi manual Google Chrome stabil adalah sebagai berikut:

wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
sudo sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list'
apt-get -y update
apt-get -y install google-chrome-stable

Tambahkan file chrome managed policies dan set CommandLineFlagSecurityWarningEnabled ke false untuk menyembunyikan warning dari Chrome:

sudo mkdir -p /etc/opt/chrome/policies/managed
sudo sh -c 'echo '{ "CommandLineFlagSecurityWarningsEnabled": false }' >> /etc/opt/chrome/policies/managed/managed_policies.json'

Selanjutnya install Chromedriver dengan perintah dibawah ini:

CHROME_DRIVER_VERSION=`curl -sS chromedriver.storage.googleapis.com/LATEST_RELEASE`
wget -N http://chromedriver.storage.googleapis.com/$CHROME_DRIVER_VERSION/chromedriver_linux64.zip -P ~/
unzip ~/chromedriver_linux64.zip -d ~/
rm ~/chromedriver_linux64.zip
sudo mv -f ~/chromedriver /usr/local/bin/chromedriver
sudo chown root:root /usr/local/bin/chromedriver
sudo chmod 0755 /usr/local/bin/chromedriver

Repository Jitsi dan Instalasi Jibri

Paket Jibri terdapat di repository Jitsi, jadi kita perlu menambahkan Jitsi ke dalam repository Ubuntu Server dengan perintah:

echo 'deb https://download.jitsi.org stable/' | sudo tee \ /etc/apt/sources.list.d/jitsi-stable.list
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo \ apt-key add -
sudo apt-get update

Selanjutnya kita mulai instalasi Jibri terbaru dengan perintah:

sudo apt-get install jibri

Agar dapat bekerja dengan baik, sebaiknya kita juga memasukan user jibri ke dalam beberapa grup berikut:

sudo usermod -aG adm,audio,video,plugdev jibri

File Konfigurasi Jibri

File konfigurasi Jibri terdapat di /etc/jitsi/jibri/jibri.conf. Contoh konfigurasinya dapat dilihat di reference.conf untuk default values dan contoh bagaimana membuat jibri.conf. Di bawah ini adalah contoh file konfigurasi jibri.conf yang digunakan penulis:

jibri {
  // A unique identifier for this Jibri
  // TODO: eventually this will be required with no default
  id = ""
  // Whether or not Jibri should return to idle state after handling
  // (successfully or unsuccessfully) a request.  A value of 'true'
  // here means that a Jibri will NOT return back to the IDLE state
  // and will need to be restarted in order to be used again.
  single-use-mode = false
  api {
    http {
      external-api-port = 2222
      internal-api-port = 3333
    }
    xmpp {
      // See example_xmpp_envs.conf for an example of what is expected here
      environments = [
              {
                name = "prod environment"
                xmpp-server-hosts = ["meet.yourdomain.com"]
                xmpp-domain = "meet.yourdomain.com"

                control-muc {
                    domain = "internal.auth.meet.yourdomain.com"
                    room-name = "JibriBrewery"
                    nickname = "jibri"
                }

                control-login {
                    domain = "auth.meet.yourdomain.com"
                    username = "jibri"
                    password = "jibriauthpass"
                }

                call-login {
                    domain = "recorder.meet.yourdomain.com"
                    username = "recorder"
                    password = "jibrirecorderpass"
                }

                strip-from-room-domain = "conference."
                usage-timeout = 0
                trust-all-xmpp-certs = true
            }]
    }
  }
  recording {
    recordings-directory = "/srv/recordings"
    # TODO: make this an optional param and remove the default
    finalize-script = "/srv/finalize.sh"
  }
  streaming {
    // A list of regex patterns for allowed RTMP URLs.  The RTMP URL used
    // when starting a stream must match at least one of the patterns in
    // this list.
    rtmp-allow-list = [
      // By default, all services are allowed
      ".*"
    ]
  }
  chrome {
    // The flags which will be passed to chromium when launching
    flags = [
      "--use-fake-ui-for-media-stream",
      "--start-maximized",
      "--kiosk",
      "--enabled",
      "--disable-infobars",
      "--autoplay-policy=no-user-gesture-required"
    ]
  }
  stats {
    enable-stats-d = true
  }
  webhook {
    // A list of subscribers interested in receiving webhook events
    subscribers = []
  }
  jwt-info {
    // The path to a .pem file which will be used to sign JWT tokens used in webhook
    // requests.  If not set, no JWT will be added to webhook requests.
    # signing-key-path = "/path/to/key.pem"

    // The kid to use as part of the JWT
    # kid = "key-id"

    // The issuer of the JWT
    # issuer = "issuer"

    // The audience of the JWT
    # audience = "audience"

    // The TTL of each generated JWT.  Can't be less than 10 minutes.
    # ttl = 1 hour
  }
  call-status-checks {
    // If all clients have their audio and video muted and if Jibri does not
    // detect any data stream (audio or video) comming in, it will stop
    // recording after NO_MEDIA_TIMEOUT expires.
    no-media-timeout = 90 seconds

    // If all clients have their audio and video muted, Jibri consideres this
    // as an empty call and stops the recording after ALL_MUTED_TIMEOUT expires.
    all-muted-timeout = 10 minutes

    // When detecting if a call is empty, Jibri takes into consideration for how
    // long the call has been empty already. If it has been empty for more than
    // DEFAULT_CALL_EMPTY_TIMEOUT, it will consider it empty and stop the recording.
    default-call-empty-timeout = 30 seconds
  }
}

Selanjutnya, aktifkan jibri agar berjalan otomatis ketika sistem dinyalakan dengan perintah:

sudo systemctl enable jibri
sudo systemctl restart jibri

Setelah selesai melakukan rekaman, file rekaman Jibri akan tersimpan di direktori /srv/recordings/. Kita juga bisa menambahkan file finalize.sh di direktori /srv/finalize.sh yang akan dijalankan setiap jibri selesai merekam. File finalize.sh dapat diisi dengan script untuk mengunggah hasil rekaman ke cloud storage atau yang lain sesuai keinginan.

Referensi

Github Jitsi/Jibri. https://github.com/jitsi/jibri
Coders, N. (2021, July 28). How to change default kernel in Ubuntu (AWS) (Jibri). NIMBLE CODERS. https://nimblecoders.in/how-to-change-default-kernel-in-ubuntu-aws/
Saiflakhani, S. (2021, February 24). [Setup / Guide] Jitsi Meet Native + Multiple (6) Jibri Docker instances working on the same AWS server. Community.Jitsi.Org. https://community.jitsi.org/t/setup-guide-jitsi-meet-native-multiple-6-jibri-docker-instances-working-on-the-same-aws-server/

Menambahkan Autentikasi pada Jitsi Meet Server

febryandana — Thu, 28 Oct 2021 03:29:38 +0000

Jitsi mendukung beberapa metode autentikasi seperti SIP, LDAP, dan plain account. Pada artikel ini, kita akan mencoba membuat autentikasi menggunakan plain account yang dibuat langsung menggunakan Prosody.

Konfigurasi Prosody

Buka file konfigurasi domain di prosody dengan menggunakan nano atau text editor lainnya.

nano /etc/prosody/conf.d/meet.yourdomain.com.cfg.lua

Cari VirtualHost yang berisi domain Jitsi Meet kita, lalu ubah value authentication menjadi internal_hashed

VirtualHost "meet.yourdomain.com"
        -- enabled = false -- Remove this line to enable this host
        -- authentication = "anonymous"
        authentication = "internal_hashed"
...

Kemudian, tambahkan VirtualHost baru dalam file yang sama untuk menampung guest. Domain guest ini bersifat internal only sehingga tidak memerlukan DNS record atau sertifikat SSL baru.

...
VirtualHost "guest.meet.yourdomain.com"
    authentication = "anonymous"
    c2s_require_encryption = false

Simpan file untuk mengonfirmasi perubahan.

Menambahkan guest domain ke Jitsi Meet

Setelah mengatur Prosody XMPP Server untuk mengaktifkan fitur autentikasi, selanjutnya kita perlu memberi tahu Jitsi Meet tentang VirtualHost guest yang baru kita buat. Caranya adalah dengan membuka file berikut menggunakan text editor.

nano /etc/jitsi/meet/meet.yourdomain.com-config.js

Cari variabel anonymousdomain pada blok hosts, lalu tambahkan domain guest.yourdomain.com sebagai value-nya.

    hosts: {
        // XMPP domain.
        domain: 'meet.yourdomain.com',

        // When using authentication, domain for guest users.
        // anonymousdomain: 'guest.example.com',
        anonymousdomain: 'guest.meet.yourdomain.com',
...

Simpan dan tutup file tersebut untuk mengonfirmasi perubahan.

Konfigurasi Jicofo

Selanjutnya kita perlu mengatur komponen Jitsi Conference Focus (Jicofo) untuk mengizinkan request hanya dari authenticated domain saja. Buka file berikut dengan text editor.

nano /etc/jitsi/jicofo/sip-communicator.properties

Tambahkan key-value baru berikut ke dalam file dan simpan.

...
org.jitsi.jicofo.auth.URL=XMPP:meet.yourdomain.com

Membuat akun moderator

Tahap terakhir adalah membuat akun moderator yang memiliki izin untuk membuat conference room di Jitsi Meet Server. Kita bisa menggunakan layanan prosodyctl untuk membuat akun ini.

sudo prosodyctl register USERNAME meet.yourdomain.com PASSWORD

Pastikan untuk membuat username dan password yang unik agar tidak mudah diretas. Pastikan juga untuk menyimpan kredensial username dan password tersebut di tempat yang aman dan tidak mudah lupa.

Restart semua Jitsi service

Setelah selesai melalukan konfigurasi di atas, restart layanan Jitsi dengan perintah berikut.

sudo systemctl restart prosody
sudo systemctl restart jicofo
sudo systemctl restart nginx

# Jika Jitsi Meet diatur untuk menggunakan videobridge dalam satu server yang sama:
sudo systemctl restart jitsi-videobridge2

Cek file log

Untuk melihat log aktifitas dari layanan Jitsi, kita bisa menggunakan perintah berikut.

# Log Prosody
tail -f /var/log/prosody/prosody.log

# Log Jicofo
tail -f /var/log/jitsi/jicofo.log

# Log Nginx
tail -f /var/log/nginx/error.log

# Log Jitsi Video Bridge
tail -f /var/log/jitsi/jvb.log

Selesai

Kita bisa mengetesnya langsung dengan membuka domain Jitsi Meet dan mencoba membuat conference room. Seharusnya Jitsi akan memunculkan notifikasi "Waiting for the host". Pilih "I am the host" lalu masukkan kredensial akun yang telah dibuat sebelumnya. Baru lah setelah moderator masuk, peserta conference lainnya dapat saling berinteraksi.

Referensi

Kirstätter, J. (2020, May 3). Enable authentication in your instance of jitsi meet. Get Blogged by JoKi. Retrieved August 28, 2021, from https://jochen.kirstaetter.name/authentication-jitsi-meet/.

Instalasi Jitsi Meet Sebagai Alternatif Open Source Video Conference

febryandana — Wed, 27 Oct 2021 12:05:46 +0000

Di masa modern sekarang, terutama saat pandemi COVID-19 seperti ini, banyak instansi swasta, pemerintah, maupun pendidikan yang terpaksa untuk meniadakan interaksi tatap muka dan mengharuskan semuanya dilakukan dari rumah (Work from Home, School from Home). Salah satu tool/aplikasi yang paling populer digunakan adalah online video conference untuk menggantikan rapat atau pertemuan tatap muka secara online. Ada banyak sekali layanan yang menyediakan fitur online video conference seperti Google Meet, Zoom, Skype, Microsoft Teams, Discord, dan lain-lain.

Sayangnya sebagian besar layanan tersebut sifatnya komersial dan closed source sehingga fitur-fiturnya terbatas atau mengharuskan untuk membayar biaya langganan. Oleh karena itu mulai banyak yang melirik alternatif lain yang lebih luwes dengan fitur melimpah tanpa harus membayar biaya langganan. Salah satunya alternatif tersebut adalah Jitsi Meet, sebuah layanan Video Conference yang 100% gratis dan open source dari Jitsi. Jitsi Meet memiliki banyak sekali fitur yang menarik seperti autentikasi berbasis SIP dan LDAP, fitur livestreaming ke Youtube atau video streaming lainnya, end-to-end encryption, akses tanpa batas waktu, dan lain-lain. Karena merupakan produk open source, Jitsi Meet juga menyediakan paket instalasi yang dapat dipasang di server milik sendiri dengan custom domain. Salah satu contohnya adalah meet.jit.si yang sudah disediakan oleh Jitsi sendiri.

Kali ini kita akan mencoba melakukan instalasi Jitsi Meet pada server milik sendiri dengan custom domain. Beberapa hal yang perlu diperhatikan antara lain :

Spesifikasi mesin. Karena berfungsi sebagai video conference, Jitsi Meet membutuhkan spesifikasi server yang cukup kuat untuk dapat menampung beban audio dan video dari user. Semakin banyak user maka bebannya juga akan semakin berat sehingga butuh spesifikasi sistem yang semakin tinggi.
Custom domain. Jitsi Meet dapat digunakan tanpa custom domain, tetapi ini menyebabkan kita tidak bisa memanfaatkan fitur SSL untuk HTTPS dan keamanan end-to-end encryption. Penulis sangat merekomendasikan untuk menyiapkan custom domain atau subdomain khusus untuk Jitsi Meet. Kita juga perlu mengalokasikan IP public static dengan Elastic IP agar tautan IP Address ke domain tidak berubah-ubah.
Firewall. Berikut adalah port yang perlu dibuka atau diberi izin akses agar Jitsi Meet dapat bekerja dengan baik :

Pada artikel ini kita akan mencoba melakukan instalasi Jitsi Meet pada sistem operasi Ubuntu Server 18.04 dari AWS EC2 Instance. Panduan instalasi ini juga dapat digunakan untuk Ubuntu Server 20.04. Jika belum tahu bagaimana cara membuat EC2 Instance, kalian bisa membaca Membuat EC2 Instance pada AWS.

Instalasi Jitsi Meet pada Ubuntu Server 18.04 AWS

Untuk memudahkan proses, semua domain yang ada di bawah menggunakan meet.yourdomain.com. Kalian harus mengubahnya ke domain kalian sendiri.

Pertama-tama kita perlu memperbarui sistem Ubuntu kita dengan,

sudo apt-get update && sudo apt-get upgrade -y

Selanjutnya ubah hostname dari Ubuntu Server dengan perintah

sudo hostnamectl set-hostname meet.yourdomain.com

Edit file /etc/hosts dengan menambahkan IP public server dan subdomain meet.yourdomain.com

sudo nano /etc/hosts

Jika belum ada, tambahkan baris berikut di bagian awal file:

Baris 1 : `127.0.0.1 localhost`
Baris 2 : `IP_PUBLIC_SERVER meet.yourdomain.com`

Simpan dengan Ctrl+S dan keluar dengan Ctrl+X

Install beberapa dependencies yang perlu dipersiapkan untuk menggunakan Jitsi Meet. Seharusnya dependencies ini sudah terinstall tetapi sebaiknya kita cek ulang :

sudo apt install -y apt-transport-https

Selanjutnya tambahkan Jitsi ke repository Ubuntu Server dengan perintah :

echo 'deb https://download.jitsi.org stable/' | sudo tee \ /etc/apt/sources.list.d/jitsi-stable.list
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -
sudo apt-get update

Setelah semuanya selesai selanjutnya kita akan mulai melakukan instalasi Jitsi Meet dengan memberikan perintah instalasi :

sudo apt install -y jitsi-meet

Proses instalasi akan berlangsung. Jitsi Meet akan diinstall beserta dengan dependencies yang diperlukan.

Jika muncul dialog masukan untuk hostname, masukkan meet.yourdomain.com (ganti dengan domain kalian). Pastikan untuk mengetik hostname dengan benar tanpa kesalahan.

Ketika muncul dialog tentang certification, pilih self-signed certification karena selanjutnya kita akan memanfaatkan Let's Encrypt untuk mendapatkan SSL certification.

Setelah proses instalasi selesai, selanjutnya kita akan membuat self-signed SSL certificate dengan memanfaatkan Let's Encrypt. Masukkan perintah berikut untuk memulai proses pembuatan sertifikat :

sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

Saat diminta, masukkan hostname domain Jitsi Meet dan email kalian lalu tunggu proses sertifikasi berjalan hingga selesai.

Selanjutnya kita dapat meningkatkan system limit dengan mengedit file /etc/systemd/system.conf :

sudo nano /etc/systemd/system.conf

Pergi ke bagian bawah file lalu tambahkan baris berikut :

DefaultLimitNOFILE=65000
DefaultLimitNPROC=65000
DefaultTasksMax=65000

Restart service dengan perintah :

sudo systemctl daemon-reload
sudo systemctl restart {prosody,jicofo,jitsi-videobridge2,nginx}

Sampai tahap ini Jitsi Meet telah selesai di-install. Untuk mengujinya, buka browser dan pergi ke https://meet.yourdomain.com. Sekarang Jitsi Meet kita sudah siap digunakan, tetapi masih terdapat beberapa fitur yang belum tersedia seperti fitur record, livestreaming, dan autentikasi user. Panduan penambahan fitur record, autentikasi, dan kustomisasi home page akan dipecah ke dalam artikel selanjutnya.

Referensi

Github Jitsi Meet
Jitsi Meet Website
Jitsi Wikipedia entry
Saiflakhani, S. (2021, February 24). [Setup / Guide] Jitsi Meet Native + Multiple (6) Jibri Docker instances working on the same AWS server. Community.Jitsi.Org. https://community.jitsi.org/t/setup-guide-jitsi-meet-native-multiple-6-jibri-docker-instances-working-on-the-same-aws-server/

Kelola Server Lewat Website Dengan Cockpit

febryandana — Sat, 21 Aug 2021 03:53:47 +0000

Kebanyakan system administrator mengelola server mereka melalui koneksi SSH dengan antarmuka CLI, bukan GUI. Meskipun umum digunakan, tetap ada sebagian kecil orang yang merasa bahwa command line interface itu susah digunakan, dan merasa mengintimidasi. Karena salah satu karakter saja bisa menyebabkan server crash.

Tapi bukan berarti tidak ada jalan lain. Karena sekarang sudah banyak alat-alat manajemen server yang berbasis grafis dan mudah digunakan. Contohnya seperti Webmin dan Cockpit. Tools ini bertujuan untuk memudahkan sysadmin mengelola sistem linux mereka tanpa ribet dengan urusan SSH key, salah ketik perintah, atau untuk mengurus banyak server sekaligus tanpa perlu berpindah-pindah terminal SSH.

Pada artikel ini, kita akan mencoba untuk melakukan instalasi Cockpit di Ubuntu Server yang ada di AWS. JIka kalian belum tahu bagaimana cara membuat virtual machine Ubuntu Server di AWS, kalian dapat melihat artikel Membuat EC2 Instance pada AWS terlebih dahulu.

Instalasi Paket Cockpit

Instalasi Cockpit sangat sederhana. Hanya ada satu package yang perlu dipasang dan untungnya, paket instalasi Cockpit sudah tersedia di hampir semua package manager. Yang perlu diperhatikan adalah bahwa Cockpit secara default memakai port TCP/9090 untuk akses ke website-nya sehingga kita perlu membuka firewall untuk port tersebut.

Jika menggunakan AWS EC2 Instance, kita bisa memodifikasi Security Group yang terhubung dengan Instance tempat Cockpit berada. Jika menggunakan aplikasi firewall seperti UFW, kita harus menambahkan aturan baru untuk mengizinkan akses masuk ke port TCP/9090 dengan perintah :

sudo ufw allow 9090

Paket instalasi Cockpit sudah tersedia dalam repositori Ubuntu sehingga untuk memasangnya kita cukup memberikan perintah :

sudo apt-get install -y cockpit

Jika kalian menggunakan sistem lain, Cockpit juga sudah menyediakan panduan instalasi untuk banyak sistem operasi yang bisa dilihat di cockpit-project.org/running. Cockpit sudah mendukung sebagian besar distro Linux seperti Debian, Red Hat Linux Enterprise, Fedora, Arch, dll.

Setelah sistem menyelesaikan instalasi, cockpit dapat langsung diakses di http://SERVER_PUBLIC_IP:9090 atau di http://YOUR_DOMAIN.COM:9090.

SERVER_PUBLIC_IP dan YOUR_DOMAIN.COM hanya contoh, gunakan IP Address atau domain yang ada di server Cockpit kalian sendiri.

Tampilan Cockpit

Gambar di atas adalah tampilan login page Cockpit ketika pertama kali diakses. Untuk masuk ke dalam Cockpit kita perlu memberikan user name dan password sistem.
Dalam beberapa kasus seperti Instance di AWS, secara default kita tidak memiliki password untuk user sistem. Untuk itu kita bisa memberikan sendiri password-nya dengan perintah:

sudo passwd $USER

Perintah ini berguna untuk mengganti password dari user. Setelah password selesai dibuat, kita bisa masuk Cockpit menggunakan username dari $USER dan password yang baru kita buat.

Ketika kita sudah masuk, kita akan disambut menu Host yang berisi layanan-layanan dari Cockpit seperti Overview, Logs, Storage, dan sebagainya yang akan dibahas lebih lanjut. Di bawah menu Host terdapat menu Dashboard yang berisi grafik penggunaan secara real time dari komponen CPU, Memory, Network, dan Disk I/O. Desain antarmuka pengguna dari Cockpit cukup sederhana dan intuitif sehingga mudah digunakan bahkan oleh pemula sekalipun.

Salah satu kelebihan Cockpit adalah kita bisa menambahkan server lain ke dalam Cockpit sehingga satu halaman Cockpit saja bisa digunaka untuk mengelola semua server yang kita miliki. Kita akan mencoba fitur ini di bagian akhir artikel.

Daftar Layanan Cockpit

Overview

Pada bagian Overview kita bisa melihat ringkasan dari sistem seperti kesehatan sistem, penggunaan CPU dan Memory, informasi sistem, dan konfigurasi sistem

Logs

Pada bagian Logs ditampilkan daftar error, peringatan, dan informasi log penting lainnya dari sistem. Kita dapat melihat logs dari range waktu tertentu

Storage

Pada bagian Storage ditampilkan daftar perangkat dan drive storage yang terhubung, detail filesystem dan sisa penggunaan storage, informasi logs dari storage, serta grafik real time usage dari aksi Baca/Tulis perangkat storage.

Networking

Di bagian ini, kita bisa melihat daftar perangkat kartu jaringan dan grafik dari trafik penggunaan jaringan (send/receive). Kita juga bisa melihat informasi logs tentang status jaringan dari sistem.

Accounts

Di bagian Account, terdapat daftar akun yang ada di dalam sistem. Di dalamnya kita bisa memodifikasi beberapa pengaturan akun seperti Role administrator, mengunci akses akun, mengganti password, dan lain-lain.

Services

Bagian Services menampilkan daftar services yang aktif maupun non-aktif yang ada di dalam sistem. Disini kita bisa mengatur status services, mengatur automatic startup, menambahkan/menghapus path, dan lain-lain.

Applications

Bagian Applications menampilkan daftar plugin aplikasi yang dapat digunakan oleh Cockpit. Kita bisa menambahkan atau mematikan aplikasi Cockpit melalui menu ini. Daftar aplikasi Cockpit yang tersedia dapat dilihat di cockpit-project.org/applications.

Software Updates

Kita bisa melakukan update sistem secara keseluruhan maupun per software melalui menu Software Updates.

Terminal

Selain kontrol menggunakan GUI, Cockpit juga memiliki built-in terminal untuk mengelola sistem melalui command line. Dengan adanya built-in terminal, kita tidak perlu menggunakan SSH atau tool komunikasi lain untuk mengakses server, semuanya cukup menggunakan satu halaman Cockpit. Dengan terminal ini kita bisa melakukan apa saja ke dalam sistem seperti memasang aplikasi baru, mengganti file konfigurasi, manipulasi teks atau file, dan lain-lain.

Mengelola Server Lain Melalui Cockpit

Selanjutnya kita akan mencoba menambahkan server baru untuk dikelola dalam satu Cockpit. Untuk mengakses server lain, Cockpit memanfaatkan layanan SSH dengan menggunakan proses cockpit-bridge. Cockpit mengakses server lain melalui password based authentication sehingga kita harus mengaktifkan opsi tersebut terlebih dahulu. Untuk mengaktifkan password based authentication, kita cukup memodifikasi satu baris di /etc/ssh/sshd_config :

sudo nano /etc/sshd/sshd_config

Cari baris "PasswordAuthentication no" dan ubah menjadi "PasswordAuthentication yes" (tanpa tanda kutip). Simpan file dengan Ctrl+S dan keluar dengan Ctrl+X . Kemudian restart service SSHD dengan perintah :

sudo systemctl restart sshd

Tahap selanjutnya akan dilakukan melalui website Cockpit di server utama kita. Pertama kita masuk ke dalam Dashboard Cockpit, lalu klik tombol "+" biru di sebelah kanan atas dari tabel Servers.

Akan muncul dialog Add Machine to Dashboard. Masukkan IP Address atau hostname dari mesin yang akan kita kelola,pilih warna identitasnya, lalu klik Add. Jika semua server yang akan dikelola berada dalam satu jaringan yang sama, lebih baik gunakan hostname atau IP Address lokal untuk mengurangi latency dan beban jaringan ke luar (internet).

Selanjutnya akan muncul dialog Log in to server. Masukkan username server lain, ubah autentikasinya menggunakan password, lalu masukkan password user server lain tersebut dan klik Log in.

Jika proses Log in berhasil, seharusnya akan muncul item berupa hostname dari server baru tersebut di tabel Servers. Grafik penggunaannya juga akan muncul di bagian grafik dengan warna yang sudah ditentukan sebelumnya.

Kita bisa memulai mengelola server lain dengan menekan hostname di menu Host lalu memilih hostname server lain.

Kita bisa menambahkan sistem server lain sebanyak yang kita mau selama semua server tersebut berhasil dipasang paket Cockpit tanpa ada masalah perbedaan sistem operasi. Cockpit cukup dapat diandalkan baik oleh pemula maupun sysadmin yang sudah berpengelaman untuk mengelola sistem server. Dengan Cockpit, kita bisa mengelola banyak remote server secara sekaligus dalam satu tempat tanpa perlu berganti-ganti perangkat atau SSH. Kita bisa mengelola banyak hal dengan memanfaatkan Cockpit seperti memasang aplikasi baru, mengecek load penggunaan CPU dan Memory, mengubah status services, reboot dan shutdown server, dan lain sebagainya.

Referensi

Membuat EC2 Instance pada AWS

febryandana — Wed, 18 Aug 2021 15:12:47 +0000

AWS Elastic Compute Cloud (EC2) adalah salah satu service dari Amazon Web Service yang paling populer digunakan. EC2 adalah service yang menawarkan komponen cloud computing seperti virtual machine yang Amazon sebut sebagai Instance yang memiliki banyak pilihan spesifikasi, Amazon Machine Image (AMI) yang merupakan kumpulan OS image yang dapat dipasang untuk Instance, Elastic IP yang merupakan IPv4 Public statis cocok digunakan untuk DNS record, Amazon Elastic Block Store (Amazon EBS) sebagai persistent storage, dan lain-lain yang bisa dilihat sendiri disini.

Membuat EC2 Instance di AWS cukup sederhana, hanya ada beberapa tahap yang perlu dilakukan.

0. Persiapan - Masuk ke layanan EC2 pada AWS Console

Sebelum membuat EC2 Instance, pertama-tama siapkan dulu kebutuhan sistem yang akan digunakan. Perkirakan seberapa berat beban komputasi yang akan ditanggung dan seberapa besar spesifikasi mesin yang cukup untuk menanggungnya. Setelah itu baru kita masuk ke tahap awal dari membuat EC2 instance, yaitu masuk ke dalam AWS Console. Pastikan akun yang kita gunakan memiliki akses untuk EC2, kemudian pilih layanan EC2 di bagian All Services. Gambar di atas adalah tampilan dashboard utama dari layanan EC2, untuk membuat Instance baru, kita bia memilih tombol "Launch instance".

1. Memilih AMI (Amazon Machine Image) dari OS yang akan digunakan

Selanjutnya kita akan disambut oleh menu pilihan AMI. Kita bisa memilih AMI yang direkomendasikan AWS di bagian Quick Start, menggunakan AMI milik kita sendiri jika ada, atau memilih untuk menggunakan AMI yang ada di AWS Marketplace atau AMI milik komunitas.

2. Memilih spesifikasi Instance

Tahap selanjutnya adalah memilih jenis dan spesifikasi Instance yang akan digunakan. AWS menyediakan banyak sekali spesifikasi Instance yang dapat dipilih, pilihan spesifikasi Instances dibedakan sebagai "family", mulai dari keluarga T, C, M, R dan sebagainya. Penjelasan lebih lanjut tentang pilihan Instance bisa dilihat disini.

3. Mengatur detail Instance

Spesifikasi Instance yang kita pilih dapat diatur lebih lanjut di tahap ini. Disini kita bisa mengatur jumlah Instance yang akan dibuat, pilihan pembayaran, jaringan dan subnet yang digunakan, IAM Role, monitoring, dan lain sebagainya. Setelah dirasa cukup, kita bisa melanjutkan ke tahap berikutnya.

4. Memberi storage untuk Instance

Tahap selanjutnya adalah mengatur ukuran dan tipe media penyimpanan yang akan digunakan. Minimal satu volume harus ada sebagai Root Volume. Kita bisa memilih kapasitas storage dengan bebas tetapi sebaiknya disesuaikan dengan kebutuhan karena setiap GB dari storage ini akan tetap dihitung biayanya (kecuali jika masih dalam batasan Free Tier). Kita juga bisa memilih tipe volume dan enkripsi yang akan digunakan untuk volume tersebut. Penjelasan lengkap untuk EC2 Storage ini dapat dibaca disini.

5. Memberi tag pada instance

Langkah kelima ini sebenarnya opsional. Tanpa tag pun kita masih bisa membuat Instance. Tetapi best practice-nya memang sebaiknya kita memberikan tag untuk setiap komponen AWS yang dibuat agar lebih mudah dalam manajemen. Paling tidak berikan Name tag untuk membedakan nama setiap Instance yang akan dibuat.

6. Mengatur Security Group untuk keamanan Instance

Tentunya kita pasti tidak ingin Instance kita dapat dibobol dengan mudah oleh orang lain bukan? Oleh karena itu tahap keenam ini menjadi bagian yang cukup krusial karena berhubungan dengan keamanan Instance. Pastikan untuk hanya membuka protokol dan port yang memang benar-benar dibutuhkan saja. Untuk keamanan lebih, kita juga bisa membatasi hanya IP Address dari sumber tertentu saja yang dapat mengakses Instance. Penjelasan lebih lanjut tentang EC2 Security Group dapat dibaca disini.

7. Pengecekan terakhir dan meluncurkan Instance

Tahap terakhir dari pembuatan EC2 Instance adalah review. Di tahap ini kita disuguhkan detail dari konfigurasi Instance yang sudah kita buat sebelumnya. Pastikan bahwa pengaturan yang dibuat sudah sesuai dengan apa yang kita butuhkan agar tidak repot mengatur ulang nantinya. Jika dirasa sudah yakin, kita lanjutkan dengan menekan tombol "Launch" untuk meluncurkan Instance.

Sebelum meluncurkan Instance, kita akan diberikan jendela terakhir dimana kita harus memilih SSH key pair untuk mengakses Instance nantinya. Kita bisa memilih untuk membuat key baru, memilih dari yang sudah ada, atau melanjutkan tanpa key. Simpan SSH key yang dibuat dengan baik karena kita tidak bisa mengunduhnya ulang setelah Instance dibuat. Setelah itu lanjutkan dengan menekan tombol "Launch Instances" untuk menyelesaian pembuatan AWS EC2 Instance.

Detail Instance yang telah dibuat dapat dilihat di menu "Instances" dari daftar menu sebelah kiri. Disini kita bisa melihat detail Instance, Security, Networking, dan lain-lain. Selain itu kita juga bisa menghentikan dan menghapus Instance. Ada juga pilihan Actions seperti untuk menghubungi Instance, mengganti tipe Instance, mengubah Security Group, dan lain-lain. AWS EC2 memberikan kemudahan dan kontrol yang sangat luas terhadap cloud computer yang kita buat.

Mematikan EC2 Instance

Untuk menghemat biaya, sebaiknya kita mematikan EC2 Instance yang sudah tidak digunakan. Cara mematikan dan menghapus EC2 Instance sangat sederhana. Pertama-tama masuk ke dalam EC2 Dashboard dan pilih menu Instances. Kemudian centang Instance yang ingin dimatikan atau ingin dihapus. Selanjutnya klik pada menu Instance State di sebelah kanan atas. Akan muncul pilihan menu status instance :

Stop Instance : Untuk mematikan Instance tanpa menghapusnya. Biaya Instance masih akan tetap berjalan meskipun Instance berhenti
Start Instance : Untuk menjalankan kembali Instance yang sudah di-stop
Reboot Instance : Untuk memuat ulang Instance
Hibernate Instance : Untuk menghibernasi Instance
Terminate Instance : Untuk menghapus Instance

Item yang terhapus termasuk Instance, Network Interface, dan Volume storage beserta data-data yang ada di dalamnya. Instance yang telah terhapus tidak dapat dikembalikan, karena itu sebelum menghapus Instance pastikan bahwa sudah tidak ada data penting di dalamnya dan Instance benar-benar sudah tidak dibutuhkan lagi.

Mengakses Ubuntu di Cloud Menggunakan xrdp

febryandana — Wed, 04 Aug 2021 05:26:50 +0000

Kita bisa mengakses Ubuntu server yang ada di cloud seperti AWS, GCP, DigitalOcean, dll dengan menggunakan GUI daripada melalui SSH seperti yang biasa digunakan. Manfaatnya? Tidak begitu banyak. Justru cenderung lebih banyak kekurangan yang perlu diperhatikan seperti tambahan beban kerja yang tidak diperlukan, tambahan aplikasi-aplikasi yang mungkin akan jarang dipakai, dan beban jaringan yang lebih berat karena harus mengirim lebih banyak data.

Tapi bukan berarti GUI untuk Ubuntu server tidak berguna. Kalian bisa memanfaatkan Ubuntu GUI di cloud tersebut sebagai pengganti desktop, untuk menyimpan data jauh lebih banyak, atau memanfaatkannya untuk mengunduh file-file besar menggunakan jaringan internet dari cloud provider yang lebih cepat dan stabil. Bisa juga digunakan untuk melakukan administrasi server dengan aplikasi versi GUI yang lebih user friendly.

Pada artikel ini, penulis menggunakan OS Ubuntu Server 20.04 LTS yang dipasang di AWS EC2. Tidak ada perhatian khusus selain layanan Security Group pada EC2 sehingga perintah-perintah ini dapat direplikasi untuk sistem lain yang berbasis Ubuntu. Desktop Environment yang digunakan adalah LXDE dengan pertimbangan ukurannya yang kecil dan ringan tetapi memiliki layanan yang lengkap. Kalian juga bisa memasang Desktop Environment lainnya atau memilih jalur menggunakan Window Manager.

Untuk menghubungkan komputer dengan Ubuntu LXDE di cloud, penulis menggunakan xrdp. Aplikasi xrdp adalah implementasi open source dari layanan RDP (Remote Desktop Protocol) milik Microsoft. Fitur dari xrdp antara lain :

Terhubung dengan desktop Linux dari manapun
Reconnect ke sesi yang sudah ada
Mengubah ukuran session
Dapat berperan sebagai RDP/VNC proxy
Two-way clipboard (text, bitmap, file)
Audio & microphone redirection
Drive redirection

Persiapan

Pastikan untuk membuka akses pada port TCP/3389. Hal ini dapat dilakukan pada Security Group di EC2 (kalian bisa menyesuaikan dengan cloud provider kalian sendiri). Pastikan juga untuk membuka akses port tersebut jika menggunakan firewall di dalam Ubuntu (ufw, iptables, dsb).
Pastikan sisa storage yang tersedia cukup untuk melakukan instalasi LXDE dan aplikasi bawaannya. Setidaknya siapkan ruang sebesar 2 GB.
Siapkan waktu dan teh karena proses download dan instalasinya dapat memakan waktu.
Untuk terhubung dengan Ubuntu Desktop di cloud, kita perlu memasang RDP/VNC client seperti Remmina di komputer client.

Langkah-Langkah

Masuk ke Ubuntu Server melalui koneksi SSH
Pastikan user kalian memiliki password. Jika belum ada, berikan password dengan perintah :

$ sudo passwd [namauser]

contoh :

$ sudo passwd ubuntu
Melakukan update untuk memperbarui software dan menambal keamanan Ubuntu

$ sudo apt-get update && sudo apt-get upgrade -y
Melakukan instalasi LXDE

$ sudo apt-get install lxde -y
Minum teh dan lakukan pemanasan singkat sembari menunggu instalasi berlangsung
Setelah instalasi LXDE selesai, lakukan instalasi xrdp.

$ sudo apt-get install xrdp -y
That's it. Setelah langkah-langkah di atas selesai dan sukses dijalankan, kita bisa langsung mengakses versi GUI-nya melalui RDP/VNC client.

Mengakses Ubuntu Desktop di Cloud

Buka aplikasi Remmina atau RDP/VNC client lainnya.
Gunakan public IP Address atau public DNS milik Ubuntu Server untuk terhubung ke Remmina
Masukkan user dan password user yang digunakan oleh Ubuntu Server
Selesai. Kalian telah masuk ke Ubuntu Server dengan mode GUI.

Kesimpulan

Memasang antarmuka grafis untuk Ubuntu Server di Cloud cukup sederhana dan mudah. Kita bisa memanfaatkan mode GUI di Ubuntu Server sebagai cloud PC. Jika ingin melakukan administrasi server dengan antarmuka grafis, penulis lebih menyarankan penggunaan layanan administrasi berbasis web seperti Webmin dan Cockpit.

Referensi

linuxize.com. How to Install Xrdp Server (Remote Desktop) on Ubuntu 20.04. Diakses 30 Juli 2021, dari https://linuxize.com/post/how-to-install-xrdp-on-ubuntu-20-04/
Stas, C. (2021). How to Install GUI on Ubuntu Server [Beginner's Guide]. Diakses 30 Juli 2021, dari https://itsfoss.com/install-gui-ubuntu-server/
www.australtect.net. How To Enable GUI On AWS EC2 Ubuntu server. Diakses 30 Juli 2021, dari https://www.australtech.net/how-to-enable-gui-on-aws-ec2-ubuntu-server/

Mengenal Cloud Computing

febryandana — Wed, 04 Aug 2021 05:21:44 +0000

THERE IS NO CLOUD, It's Just Someone Else's Computer

or is it?

Untuk mengetahuinya, kita harus memahami dulu tentang cloud computing. Apa itu cloud computing? Kenapa namanya cloud? Apakah komputernya memang ada di awan?

Apa Itu Cloud Computing?

Menurut newyorker.com, istilah cloud (awan) adalah simbol, sebagai metafora bahwa data kita ada di suatu tempat di luar sana, melayang, mengambang, berpindah-pindah, dan selalu ada kapan saja dan dimana saja saat kita membutuhkannya. Istilah awan juga menarik dan menggugah benak orang karena sangat berseberangan kenyataan dimana internet terdiri dari material yang nyata seperti colokan, kabel, hard disk drive, prosesor, dan lain sebagainya.

Lalu apa itu cloud computing? Menurut Ahmadreza, cloud computing adalah kemampuan untuk menyediakan sumber daya sistem komputer sesuai permintaan, terutama data storage dan computing power, tanpa campur tangan langsung dari pengguna. Secara sederhana, cloud computing adalah sebuah layanan dimana pengguna dapat memiliki sumber daya IT seperti komputer, storage, IP Address, dan lain-lain secara mudah, sangat scalable, dan dengan dengan skema harga yang dapat dipilih sesuai keinginan.

Biasanya, jika kita ingin membuat suatu data center atau server untuk suatu layanan, kita harus membangunnya sendiri mulai dari rancangan spesifikasi komputer, prediksi penggunaan di masa depan, alokasi anggaran, penyediaan tempat, kelistrikan, pendinginan dan lain-lain. Model seperti ini biasanya disebut On-Premise, dimana perangkat keras data center berada di tempat yang sama dengan pengguna dan memiliki kontrol fisik terhadap server. Karena mengurus server model On-Premise sangat merepotkan dan membutuhkan banyak uang, munculnya inovasi cloud computing menjadi angin segar yang sangat menarik. Dengan cloud, masalah-masalah tersebut akan dibebankan kepada cloud service provider. Kita cukup mengalokasikan anggaran dana dan rancangan penggunaan yang kita inginkan. Cloud computing juga sangat scalable, penggunaan sumber daya yang kita gunakan dapat dengan mudah diatur menyesuaikan kebutuhan. Penyesuaian skala seperti ini membuat biaya pengeluaran dapat ditekan serendah mungkin tanpa perlu khawatir kekurangan sumber daya untuk server.

Jenis-Jenis Cloud Computing

Model penerapan (deployment) cloud computing secara umum terbagi menjadi 3 jenis: Public Cloud, Private Cloud, dan Hybrid Cloud.

Public Cloud

Pada model penerapan Public Cloud, sumber daya IT (server, database, jaringan, dll) sepenuhnya berbasis di cloud dan dikelola oleh cloud service provider. Sumber daya IT (biasanya hardware) dari model ini akan digunakan bersama-sama dengan user lain sehingga tidak ada yang menganggur, sehingga perbandingan biaya dan penggunaan cloud dapat ditekan serendah mungkin membuat harganya lebih murah. Tetapi dengan catatan memungkinkan munculnya masalah keamanan (hacking, bencana, privasi, dll).

Private Cloud (On-Premise)

Model Private Cloud lebih mirip seperti On-Premise. Ketika menggunakan model Private Cloud, sumber daya IT yang disediakan cloud service provider akan digunakan sepenuhnya untuk 1 client saja tanpa dibagi-bagi sehingga keamanannya lebih kuat dibanding model Public Cloud. Kekurangannya ada pada harganya yang lebih mahal.

Hybrid Cloud

Hybrid Cloud adalah gabungan dari Public Cloud dan Private Cloud. Pendekatan seperti ini dapat digunakan untuk banyak situasi seperti aturan yang mengharuskan adanya data yang disimpan di data center lokal, penggunaan fungsi backup, atau untuk meningkatkan keamanan dengan menyimpan data penting dan rahasia di data center on-premise sementara aplikasinya diletakkan di public cloud untuk menjangkau pengguna secara cepat.

Selain dari model penerapannya, cloud computing juga dapat dibagi dari model arsitektur atau layanannya, yaitu Iaas, Paas, dan SaaS.

Infrastructure-as-a-Service (IaaS)

IaaS adalah layanan cloud computing dimana kita mendapat akses penuh terhadap VM yang kita pesan, sementara cloud service provider akan mengelola sumber daya dasar seperti CPU, memory, storage, jaringan, dan server fisik. Pengguna akan mendapat akses ke VM melalui SSH, dashboard GUI, atau metode lain untuk mengelola server virtual tersebut. IaaS memberikan kontrol yang luas kepada pengguna terhadap infrastuktur yang akan dibangun. Pengguna bebas melakukan hampir apa saja terhadap infrastruktur tersebut. Kelemahannya, karena diserahkan sepenuhnya kepada pengguna, cloud service provider tidak memberikan layanan keamanan yang mumpuni karena harus pengguna sendiri yang mengaturnya. Selain itu arsitektur seperti ini juga dapat menguras waktu karena pengguna harus menyiapkan environment untuk aplikasi terlebih dahulu sebelum dapat digunakan. Contoh layanan IaaS antara lain Elastic Compute Cloud dari Amazon Web Service (AWS EC2), Google Compute Engine, DigitalOcean, Microsoft Azure dan banyak penyedia VPS (Virtual Private Server) lainnya.

Platform-as-a-Service (PaaS)

PaaS berada satu tingkat di atas IaaS dimana cloud service provider selain mengelola sumber daya IT pada IaaS, mereka juga membantu mengelola software dasar seperti sistem operasi dan service-service yang dibutuhkan untuk meluncurkan aplikasi pengguna. Ini membuat kita tidak perlu membuang waktu untuk menyiapkan environment aplikasi dan bisa fokus untuk membuat dan meluncurkan aplikasi saja. Kelemahannya, keamanan yang disiapkan cenderung berfokus untuk mengamankan platform saja, bukan aplikasi. Selain itu juga dapat muncul masalah inkompatibilitas jika ternyata platform yang disediakan tidak cocok dengan aplikasi kita. Contoh layanan PaaS adalah Heroku, AWS Beanstalk, AWS RDS, dan Google App Engine.

Software-as-a-Service (SaaS)

Pada SaaS, kita benar-benar dimanjakan oleh cloud. Semua urusan cloud akan dikelola oleh cloud service provider sementara kita cukup menikmati layanan aplikasi yang sudah disediakan. Kita tidak perlu repot-repot mengurusi masalah pembuatan dan pengelolaan aplikasi atau server. Kelemahan dari SaaS biasanya fitur yang tersedia terbatas, tergantung pada penyedia layanan dan kita tidak bisa melakukan kustomisasi secara bebas. Contoh layanan SaaS adalah Google Workspace, Office 365, Dropbox, Adobe Creative Cloud, dan sebagainya.

Selain 3 di atas ada pula model arsitektur lain seperti Database as a Service (DBaaS), Bare Metal as a Service (BMaaS), dan Function as a Service (FaaS).

Di bawah ini adalah visualisasi perbandingan antara On-Premise, IaaS, PaaS, dan SaaS dari segi manajemennya:

Plus-Minus dari Cloud Computing

Ada banyak sekali manfaat dan kelebihan dari pemanfaatan cloud computing, beberapa di antaranya adalah :

Waktu deployment yang sangat cepat

Sumber daya IT pada Cloud Computing dapat digunakan dengan cepat, bahkan kurang dari satu jam. Kita tidak perlu menunggu perangkat datang, merakit server, dan melakukan instalasi macam-macam. Cukup beberapa kali klik dan cloud service provider akan langsung menyiapkan semua resource yang diperlukan.
Harga yang murah

Jika kita memilih model On-Premise maka kita akan dihadapkan oleh beban biaya yang sangat banyak, mulai dari biaya pembelian perangkat, kelistrikan, pendinginan, pembangunan ruang khusus, biaya instalasi, dll. Berbeda dengan cloud computing dimana kita cukup membayar biaya penggunaan saja karena beban-beban tersebut sudah ditanggung oleh cloud service provider.
Mampu mendunia secara instant

Karena ditempatkan di cloud alias internet, kebanyakan cloud service provider juga menyediakan IP Address public yang dapat diakses langsung melalui internet. Beberapa cloud service provider juga memiliki layanan DNS dan IP public statis, hal ini membuat kita tidak perlu memusingkan urusan langganan IP Address dan domain name. Dengan begitu, aplikasi kita dapat langsung berada di internet dan diakses oleh siapa saja, di mana saja dan kapan saja.
Skalabilitas yang luar biasa

Karena kebanyakan layanan cloud berbasiskan virtualisasi, resource pada cloud computing dapat di-scale up/scale down dengan leluasa mengikuti kebutuhan sehingga bisa menghemat biaya pengeluaran dan mengurangi adanya sumber daya yang tidak terpakai/mubazir.
Dapat diandalkan

Layanan cloud menerapkan pengelompokan berdasarkan region dan sistem redundansi pada infrastruktur data center-nya sehingga meningkatkan nilai ketersediaan (High Availabity) dan keandalan (Reliability) dari aplikasi kita. Adanya fitur backup and restore juga membuat kita tidak perlu khawatir merugi karena kehilangan data.

Namun dengan segala kelebihannya tersebut, cloud computing tetap memiliki beberapa kelemahan, seperti :

Harus selalu terhubung dengan internet

Karena berada di internet, mau tidak mau perangkat cloud dan client kita harus selalu terhubung ke internet untuk mengelola semua layanan cloud yang digunakan. Jika terjadi internet outage di data center cloud service provider, semua aplikasi kita akan berada dalam masalah besar. Masalah bandwidth juga menjadi concern utama dalam penggunaan cloud. Karena server kita diletakkan di satu tempat bersama dengan milik orang lain, dapat terjadi isu rebutan bandwidth karena jalur internet yang jauh lebih sedikit dibanding jumlah server dan masalah latency yang tinggi karena tempat data center-nya terlalu jauh dari pengguna.
Isu keamanan

Masalah keamanan dapat datang dari berbagai sisi, mulai dari kelalaian dalam mengatur firewall, bug/vulnerability pada aplikasi, kelalaian dalam mengatur izin user, dll. Tetapi dengan penggunaan cloud dapat muncul satu sisi masalah kemanan lagi, yaitu kemungkinan hardware tempat virtual server kita berada diretas, atau bahkan worst case scenario-nya adalah kemungkinan layanan cloud provider diretas dan hacker mendapat akses penuh ke semua layanan. Karena diletakkan di satu tempat, masalah pencurian, pembobolan data center dan bencana juga menjadi concern utama.
Isu privasi

Terutama ketika memilih penerapan Public Cloud, masalah privasi dapat muncul karena server virtual kita berada di tangan cloud service provider dan kita tidak tahu apa yang mungkin mereka lakukan terhadap perangkat kita. Mungkin saja ada sniffer, spyware, dan semacamnya untuk mengambil data tanpa sepengetahuan kita.
Inkompatibilitas

Terkadang ada server virtual yang mengharuskan firmware atau software-nya menggunakan versi khusus yang disediakan oleh cloud service provider. Perbedaan ini dapat menyebabkan bentrok atau ketidakcocokan dengan aplikasi kita. Ada pula layanan-layanan yang mengharuskan pengguna meng-install modul khusus yang terkadang tidak disediakan cloud service provider.
Locked vendor

Meskipun cloud service provider memiliki layanan migrasi atau integrasi dengan cloud service provider lain, kebanyakan cukup merepotkan dan cenderung disulitkan karena cloud provider pun tidak ingin kehilangan pengguna potensialnya. Selain itu perbedaan cloud service provider dapat menyebabkan munculnya masalah inkompatibilitas, perbedaan hardware/software, masalah support, dan lain-lain.

Dengan semua kekurangan dan kelebihannya tersebut, tidak dapat dipungkiri bahwa cloud computing masih menjadi topik yang hangat dibicarakan dan tetap menjadi primadona untuk meluncurkan aplikasi-aplikasi ke dunia.

Jadi apakah cloud computing hanya komputer milik orang lain? Jawaban dari pertanyaan ini bisa "ya" dan bisa "tidak". "Ya" jika kita menggunakan model Public Cloud, dimana kita hanya meminjam tempat di server fisik untuk menjalankan server virtual. "Tidak" jika kita menggunakan model Private Cloud karena perangkat cloud-nya benar-benar hanya digunakan oleh kita saja.