Why Samba? Samba facilitates file sharing between Linux and Windows and acts as a domain controller, offering services like authentication and name resolution. It’s an essential tool for businesses aiming for seamless operations in mixed OS environments.

Step-by-Step Guide to Setting Up Samba on Ubuntu at ServerStadium

1. Installation: Begin by updating your system and installing Samba:
   sudo apt-get update
sudo apt-get install samba

2. Configuration: Backup the original Samba configuration file and then edit the new one:
   sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.backup
sudo nano /etc/samba/smb.conf


   Add your desired configurations, specifying directories to share and permissions.

3. User Setup: Samba requires a dedicated user. Create one and set a password:
   sudo smbpasswd -a username

4. Access and Permissions: Ensure the shared directories have the correct permissions. Adjust as needed using chmod and chown.
5. Restart and Test: Restart the Samba service and test your setup:
   sudo service smbd restart
smbclient -L localhost -U username


Optimizing Samba on ServerStadium

1. Security: Regularly update Samba to benefit from security patches. Consider firewall configurations to restrict access.
2. Monitoring: Monitor Samba logs for any unusual activity or errors. This aids in proactive troubleshooting.
3. Integration: Integrate Samba with other services on your ServerStadium infrastructure, like backups or cloud storage, for enhanced functionality.

Conclusion Samba on Ubuntu offers a world of cross-platform file-sharing possibilities. Whether you’re running a small business or a large enterprise, Samba ensures seamless file access across your network. With ServerStadium’s dedicated servers and cloud VM solutions, you’re equipped with the perfect environment to harness Samba’s capabilities.

Ready to explore more server solutions? Navigate through ServerStadium’s knowledge base for expert articles and guides, or contact our team for tailored solutions.

The post File Sharing Made Simple: Setting Up Samba on Ubuntu with ServerStadium appeared first on ServerStadium.

Before we get started, be sure to visit our comprehensive Knowledge Base for a wealth of other useful tutorials and guides.

Step 1: Register Your Account

To kick off, you’ll need to register an account on our Registration Page. Fill out your details, and create your account. Following registration, you’ll gain access to your personal Cloud Dashboard.

Step 2: Choose Your Cloud Instance

From your Cloud Dashboard, go to the ‘Add VM’ section. Here, you’ll find a variety of cloud instance options. Select the one that suits your needs. If you need help deciding, our Instance Pricing Guide can help you.

Step 3: Install Node.js and NPM

Node.js is a JavaScript runtime built on Chrome’s V8 JavaScript engine. It’s designed to build scalable network applications. Node.js uses an event-driven, non-blocking I/O model that is lightweight and efficient.

NPM (Node Package Manager) is the default package manager for Node.js. It’s used for installing, sharing, and distributing code, managing dependencies in your projects, and much more.

To install Node.js and NPM, you can run the following commands:

You can verify the installation with nodejs -v and npm -v.

Step 4: Install MongoDB

MongoDB is a source-available cross-platform document-oriented database program. It’s classified as a NoSQL database program, which means it doesn’t use the traditional tabular relational database structure. Instead, it uses JSON-like documents with optional schemas.

To install MongoDB, run the following commands:

The first command will install MongoDB, and the second will check the status of MongoDB to ensure it’s running correctly.

Step 5: Install Express.js

Express.js, or simply Express, is a web application framework for Node.js, designed for building web applications and APIs. It’s minimalistic and flexible and provides a robust set of features for web and mobile applications.

To install Express.js, you must create a project directory, navigate to it, and initialize a new Node.js application using NPM. After that, you can install Express.js:

Step 6: Install Angular

Angular is a platform for building web applications. It provides a way to create single-page applications requiring only HTML, CSS, and JavaScript on the client side.

To install Angular, you need to install Angular CLI (Command Line Interface), a command line tool used to scaffold and build Angular apps using node.js style (commonJs) modules. Not only does it provide you with scaffolding for your apps, but it also helps you manage your entire Angular project.

Install Angular CLI globally using NPM:

You can verify the installation with ng version.

Step 7: Create Your Application

Now that your MEAN Stack is set up, you can start building your application. This involves creating an Express.js server, setting up routes for your application, connecting your application to your MongoDB database, and building your front-end with Angular.

If you’re new to the MEAN Stack, check out our introductory MEAN Stack tutorial to get a detailed walk-through of how to create your first MEAN Stack application.

Conclusion

Congratulations! You now have a MEAN Stack set up in your ServerStadium VM instance! You’re ready to dive into web application development and harness the powerful capabilities of ServerStadium’s VM instances.

Remember, our Knowledge Base is a treasure trove of tutorials, guides, and helpful tips. If you ever need assistance, don’t hesitate to contact our support team.

The post Step-by-Step MEAN Stack Setup on ServerStadium VM Instances appeared first on ServerStadium.

ServerStadium and Zimbra want to continue our best service to our dearest customers by updating the new version. This way, we can keep up with the users’ needs while keeping them secure.

Recently, the latest version has been available to be used. To get the most of its features and security protection, you must upgrade it as well as the OS version

Please follow the tutorial below:

Prerequisite:

Single-server Installation

• RAM: 8 GB minimum
• 50 GB free disk space minimum for software and logs
• OS: Ubuntu based

Environment Set

In this setup, I use Ubuntu 16.04 as a starting point for the Zimbra operating system and ZCS-8.7.11 as the version of the Zimbra Collaboration.

Zimbra has one administrative account and one user account as my initial data.

Reinstall the ZCS Version to the Latest

This section will explain reinstalling the current Zimbra Collabora to the latest version.

1. Before proceeding with the reinstall and the upgrade, please create a snapshot of the VM first – How to Make a Snapshot and Configure VM Backup in ServerStadium
2. Reinstall the ZCS version to the latest. You can get the installer based on the operating system in the following link – get zimbra collaboration open source or here for Ubuntu 16.04
3. Navigate to the extracted folder of the ZCS installer then execute the install.sh file, with options --force-upgrade and --skip-upgrade-check
4. The Zimbra installer file will scan the existing packages to upgrade and will prompt some confirmation questions to the packages that might want to be installed.

After successful reinstallation

5. Email test flow after reinstalling
   Sender: mamad@mamadngelinux.my.id
   Recipient: ahmadnromiz@gmail.com, ahmad.naufal@wowrack.com

Upgrade the OS version

To upgrade Ubuntu to the next LTS version, enter do-release-upgrade in the CLI.

Some confirmation prompts may appear during the upgrade process, with the default value of configuration set to no.

Either keep the previous configurations of the filesystem or replace them with the maintainer preferences; those are dependent on your needs.

Example:

After the OS is successfully upgraded, do the Zimbra reinstallation steps as explained in the previous section.

Please note that the latest support of Ubuntu OS for Zimbra is 20.04 LTE. Thus, we only need to upgrade the OS to the 20.04 LTE version.

Final Email Flow Test

• Sender: mamad@mamadngelinux.my.id, pop3@mamadngelinux.my.id
• Recipient: ahmadnromiz@gmail.com, ahmad.naufal@wowrack.com

Conclusion

Now you are ready to use your latest version of Zimbra and the OS. Please feel free to ask for further information about this tutorial with our support team.

Visit our knowledge base to get more tutorials and insights about technology.

The post Upgrade Zimbra and the OS Version appeared first on ServerStadium.

This article will show you the easy deployment step of Mailu on Rancher Kubernetes.

Prerequisite:

• Please enable DNSSEC on your nameserver and add it to your domain registrar (Reff link to enable DNSSEC on CloudFlare nameserver).
• Set up the Rancher Kubernetes cluster or a single node cluster (adjusting your cluster.yml file).
  • High Availability Kubernetes Using RKE in ServerStadium Part 1
  • High Availability Kubernetes Using RKE in ServerStadium Part 2
  • High Availability Kubernetes Using RKE in ServerStadium Part 3

System Preparation:

• OS: Ubuntu 22.04
• Docker Version: 20.10.x
• RAM: 8GB Memory
• vCPU: 6 Core
• Single node host

K8s Environment Set:

1. Install helm and kubectl on the Ubuntu host using the Snap package manager

snap install helm --classic -y && snap install kubectl --classic -y

2. Copy the API generated by the RKE (Rancher Kubernetes Engine) Kubernetes cluster to the kubectl config located in /root/.kube/config (create the config file if necessary). Then verify the kubectl connection.

3. Create a new project namespace on your rancher (e.g. mail-server namespace)

4. Deploy longhorn on the related rancher project and set the replica to 1. Depending on the node in the Kubernetes cluster, you might want to increase the replica to the number of worker nodes. The longhorn will be used as the storageclass in Rancher Kubernetes Cluster.

Mailu Installation

• Add the repository via:

helm repo add mailu https://mailu.github.io/helm-charts/

• Create a local values file:

helm show values mailu/mailu > values.yaml

• Edit the values.yaml to reflect your environment. The full setup example can be seen in the following code:

# Default values for mailu.
# A list of mail hostnames is required. The first will be used as primary mail hostname
hostnames:
  - mailu.example.com # Please use your real domain

# The mail domain is required. See https://github.com/Mailu/Mailu/blob/master/docs/faq.rst#what-is-the-difference-between-domain-and-hostnames
domain: example.com # Please use your real domain

# The secret key is required for protecting authentication cookies and must be set individually for each deployment
# secretKey: chang3m3!
secretKey: chang3m3!

# An initial account can automatically be created:
initialAccount:
  username: mailadmin
  domain: example.com
  password: chang3m3!


nameOverride: ""
fullnameOverride: ""
clusterDomain: cluster.local

nodeSelector: {}

# Tolerations for pod assignment
# Ref: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
tolerations: {}

# Affinity for pod assignment
# Ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
affinity: {}

database:
  # type of the database for mailu (sqlite or mysql)
  # default database is an embedded sqlite
  # for mysql, see settings below
  type: sqlite

  # type of the database for roundcube (sqlite or mysql)
  # default database is an embedded sqlite
  # for mysql, see settings below
  roundcubeType: sqlite

# For mysql/mariadb use the following config:
# Set the host to use an external database.
# If not host is set, a database instance is created by this chart.
#   type: mysql
  mysql: {}
    # host: external-db-hostname
    # root password for mysql database
    # rootPassword: chang3m3! # can only be set for embedded mysql

    # settings for mailu (required if mailu database type is "mysql")
    # database: mailu
    # user: mailu
    # password: chang3m3!

  # For an external PostgreSQL database, use the following config:
  postgresql: {}
    # host: external-db-hostname
    # database: mailu
    # user: mailu
    # password: chang3m3!

    # settings for roundcube (required if roundcube database type is "mysql" or "postgresql")
    # roundcubeDatabase: roundcube
    # roundcubeUser: roundcube
    # roundcubePassword: chang3m3!

external_relay: {}
#    host: "[domain.tld]:port"
#    username: username
#    password: SECRET
#    # username and password can also be stored as secret:
#    secretName: external-relay-secret
#    usernameKey: username
#    passwordKey: password

persistence:
  # Setings for a single volume for all apps
  # set single_pvc: false to use a per app volume and set the properties in <app>.persistence (ex. admin.persistence)
  single_pvc: true
  size: 70Gi
  accessMode: ReadWriteOnce
  #annotations:
  #  "helm.sh/resource-policy": keep
  #hostPath: /path/on/the/host
  #existingClaim: name-of-existing.claim
  #storageClass: "-"
  storageClass: "longhorn"
  #claimNameOverride: mailu-pvc

# Change this if you're using different address ranges for pods
subnet: 10.42.0.0/16

# Version of mailu docker images to use when not specified otherwise
mailuVersion: 1.9.26
#mailuVersion: 1.8

# default log level. can be overridden globally or per service
logLevel: WARNING
# local part of the postmaster email address (Mailu will use @$DOMAIN as domain part)
postmaster: postmaster

mail:
  messageSizeLimitInMegabytes: 50

  # Configuration to prevent brute-force attacks. See the documentation for further information: https://mailu.io/master/configuration.html
  authRatelimitIP: 60/hour
  authRatelimitIPv4Mask: 24
  authRatelimitIPv6Mask: 56
  authRatelimitUser: 100/day
  authRatelimitExemtionLength: 86400
  # authRatelimitExemtion:

  # Configuration to reduce outgoing spam in case of an compromised account. See the documentation for further information: https://mailu.io/1.9/configuration.html?highlight=MESSAGE_RATELIMIT
  messageRatelimit: 200/day
  # messageRatelimitExemption:

# certmanager settings
certmanager:
  enabled: true
  issuerType: ClusterIssuer
  issuerName: letsencrypt
  apiVersion: cert-manager.io/v1

# Set ingress and loadbalancer config
ingress:
  externalIngress: true
  tlsFlavor: cert
  className: ""
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
  realIpHeader: X-Forwarded-For
  realIpFrom: 0.0.0.0/0

# Frontend load balancer for non-HTTP(s) services
front:
  # logLevel: WARNING
  image:
    repository: mailu/nginx
    # tag defaults to mailuVersion
    # tag: master
  resources:
    requests:
      memory: 100Mi
      cpu: 100m
    limits:
      memory: 200Mi
      cpu: 200m
  startupProbe:
    periodSeconds: 10
    failureThreshold: 30
    timeoutSeconds: 5
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 5
  readinessProbe:
    periodSeconds: 10
    failureThreshold: 1
    timeoutSeconds: 5
  # Deployment or DaemonSet
  controller:
    kind: Deployment
  nodeSelector: {}

  # Expose front mail ports via hostPort
  hostPort:
    enabled: true

  # Expose front mail ports via external service (ClusterIP or LoadBalancer)
  externalService:
    enabled: false
    type: ClusterIP
    # LoadBalancer
    # type: LoadBalancer
    # loadBalancerIP:
    externalTrafficPolicy: Local
    annotations: {}
    pop3:
      pop3: false
      pop3s: true
    imap:
      imap: false
      imaps: true
    smtp:
      smtp: true
      smtps: true
      submission: true

admin:
  # logLevel: WARNING
  image:
    repository: mailu/admin
    # tag defaults to mailuVersion
    # tag: master
  persistence:
    size: 6Gi
    storageClass: ""
    accessMode: ReadWriteOnce
    claimNameOverride: ""
    #annotations:
    #  "helm.sh/resource-policy": keep

  resources:
    requests:
      memory: 500Mi
      cpu: 100m
    limits:
      memory: 500Mi
      cpu: 100m
  podAnnotations: {}
  startupProbe:
    periodSeconds: 10
    failureThreshold: 30
    timeoutSeconds: 5
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 5
  readinessProbe:
    periodSeconds: 10
    failureThreshold: 1
    timeoutSeconds: 5


redis:
  image:
    repository: redis
    tag: 5-alpine
  persistence:
    size: 6Gi
    storageClass: ""
    accessMode: ReadWriteOnce
    claimNameOverride: ""
    #annotations:
    #  "helm.sh/resource-policy": keep
  resources:
    requests:
      memory: 200Mi
      cpu: 100m
    limits:
      memory: 300Mi
      cpu: 200m
  startupProbe:
    periodSeconds: 10
    failureThreshold: 30
    timeoutSeconds: 5
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 5
  readinessProbe:
    periodSeconds: 10
    failureThreshold: 1
    timeoutSeconds: 5

postfix:
  # logLevel: WARNING
  image:
    repository: mailu/postfix
    # tag defaults to mailuVersion
    # tag: master
  containerSecurityContext: {}
  #    CRI-O users will need to add the following:
  #    capabilities:
  #      add:
  #        - SYS_CHROOT
  persistence:
    size: 6Gi
    storageClass: ""
    accessMode: ReadWriteOnce
    claimNameOverride: ""
    #annotations:
    #  "helm.sh/resource-policy": keep
  resources:
    requests:
      memory: 2Gi
      cpu: 500m
    limits:
      memory: 2Gi
      cpu: 500m
  startupProbe:
    periodSeconds: 10
    failureThreshold: 30
    timeoutSeconds: 5
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 5
  readinessProbe:
    periodSeconds: 10
    failureThreshold: 1
    timeoutSeconds: 5

dovecot:
  enabled: true
  # logLevel: WARNING
  image:
    repository: mailu/dovecot
    # tag defaults to mailuVersion
    # tag: master
  containerSecurityContext: {}
#    CRI-O users will need to add the following:
#    capabilities:
#      add:
#        - SYS_CHROOT
  persistence:
    size: 6Gi
    storageClass: ""
    accessMode: ReadWriteOnce
    claimNameOverride: ""
    #annotations:
    #  "helm.sh/resource-policy": keep
  resources:
    requests:
      memory: 500Mi
      cpu: 500m
    limits:
      memory: 500Mi
      cpu: 500m
  startupProbe:
    periodSeconds: 10
    failureThreshold: 30
    timeoutSeconds: 5
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 5
  readinessProbe:
    periodSeconds: 10
    failureThreshold: 1
    timeoutSeconds: 5
  # enable dovecot overrides
  # overrides:
  #   dovecot.conf: |
  #     # More info here: https://mailu.io/1.8/kubernetes/mailu/index.html#dovecot
  #     mail_nfs_index = yes
  #     mail_nfs_storage = yes
  #     mail_fsync = always
  #     mmap_disable = yes
  #     mail_max_userip_connections=100

# historically rspamd and clamav shared their volumes in this chart
# this isn't needed anymore. to maintain backward compatibility and give users
# some time to migrate we keep this here.
#
# if you want a "shared" volume keep in mind you have to use affinity rules on
# rspamd and clamav pods so that both pods are scheduled on the same node
# to keep RWO volumes working
#
# otherwise set rspamd_clamav_persistence.single_pvc to true and review
# rspamd.persistence and clamav.persistence
rspamd_clamav_persistence:
  size: 6Gi
  storageClass: ""
  accessMode: ReadWriteOnce
  claimNameOverride: ""
  single_pvc: false
  #annotations:
  #  "helm.sh/resource-policy": keep

rspamd:
  # logLevel: WARNING
  image:
    repository: mailu/rspamd
    # tag defaults to mailuVersion
    # tag: master
  persistence:
    size: 1Gi
    storageClass: ""
    accessMode: ReadWriteOnce
    claimNameOverride: ""
    #annotations:
    #  "helm.sh/resource-policy": keep
  resources:
    requests:
      memory: 300Mi
      cpu: 300m
    limits:
      memory: 300Mi
      cpu: 300m
  startupProbe: # give it 15 minutes for initial rule compilation
    periodSeconds: 10
    failureThreshold: 90
    timeoutSeconds: 5
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 5
  readinessProbe:
    periodSeconds: 10
    failureThreshold: 1
    timeoutSeconds: 5

clamav:
  enabled: true
  # logLevel: WARNING
  image:
    repository: mailu/clamav
    # tag defaults to mailuVersion
    # tag: master
  persistence:
    size: 2Gi
    storageClass: ""
    accessMode: ReadWriteOnce
    claimNameOverride: ""
    #annotations:
    #  "helm.sh/resource-policy": keep
  resources:
    requests:
      memory: 1Gi
      cpu: 1000m
    limits:
      memory: 2Gi
      cpu: 1000m
  startupProbe: # give it 10 minutes for initial freshclam update
    periodSeconds: 10
    failureThreshold: 60
    timeoutSeconds: 5
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 5
  readinessProbe:
    periodSeconds: 10
    failureThreshold: 1
    timeoutSeconds: 5
  # clamav must share a volume with rspamd. This is usually enforced by the volume itself (RWO). If you use RWM volumes and want to
  # have clamav running on the same node, add the following affinity rule:
#  affinity:
#    podAffinity:
#      requiredDuringSchedulingIgnoredDuringExecution:
#        - labelSelector:
#            matchExpressions:
#              - key: component
#                operator: In
#                values:
#                  - rspamd
#          topologyKey: kubernetes.io/hostname

roundcube:
  enabled: true
  # logLevel: WARNING
  image:
    repository: mailu/roundcube
    # tag defaults to mailuVersion
    # tag: master
  persistence:
    size: 6Gi
    storageClass: ""
    accessMode: ReadWriteOnce
    claimNameOverride: ""
    #annotations:
    #  "helm.sh/resource-policy": keep
  uri: /roundcube
  resources:
    requests:
      memory: 100Mi
      cpu: 100m
    limits:
      memory: 200Mi
      cpu: 200m
  startupProbe:
    periodSeconds: 10
    failureThreshold: 30
    timeoutSeconds: 5
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 5
  readinessProbe:
    periodSeconds: 10
    failureThreshold: 1
    timeoutSeconds: 5


webdav:
  enabled: false
  # logLevel: WARNING
  image:
    repository: mailu/radicale
    # tag defaults to mailuVersion
    # tag: master
  persistence:
    size: 6Gi
    storageClass: ""
    accessMode: ReadWriteOnce
    claimNameOverride: ""
    #annotations:
    #  "helm.sh/resource-policy": keep
  startupProbe:
    periodSeconds: 10
    failureThreshold: 30
    timeoutSeconds: 5
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 5
  readinessProbe:
    periodSeconds: 10
    failureThreshold: 1
    timeoutSeconds: 5

mysql:
  image:
    repository: library/mariadb
    tag: 10.4.10
  persistence:
    size: 6Gi
    storageClass: ""
    accessMode: ReadWriteOnce
    claimNameOverride: ""
    #annotations:
    #  "helm.sh/resource-policy": keep
  resources:
    requests:
      memory: 256Mi
      cpu: 100m
    limits:
      memory: 512Mi
      cpu: 200m
  startupProbe:
    periodSeconds: 10
    failureThreshold: 30
    timeoutSeconds: 5
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 5
  readinessProbe:
    periodSeconds: 10
    failureThreshold: 1
    timeoutSeconds: 5

fetchmail:
  enabled: false
  # logLevel: WARNING
  image:
    repository: mailu/fetchmail
    # tag defaults to mailuVersion
    # tag: master
  persistence:
    size: 6Gi
    storageClass: ""
    accessMode: ReadWriteOnce
    claimNameOverride: ""
    #annotations:
    #  "helm.sh/resource-policy": keep
  resources:
    requests:
      memory: 100Mi
      cpu: 100m
    limits:
      memory: 200Mi
      cpu: 200m
  delay: 600

Key Takeaways

There are three keys that are required to be fulfilled.

Those are the hostname, the domain name, secret key, and the initial account.

# A list of mail hostnames is required. The first will be used as primary mail hostname
hostnames:
#  - mail.example.com
#  - imap.example.com
  - mailu.example.com # Please use your real domain

# The mail domain is required. See https://github.com/Mailu/Mailu/blob/master/docs/faq.rst#what-is-the-difference-between-domain-and-hostnames
domain: example.com # Please use your real domain

# The secret key is required for protecting authentication cookies and must be set individually for each deployment
# secretKey: chang3m3!
secretKey: chang3m3!

# An initial account can automatically be created:
initialAccount:
  username: mailadmin
  domain: example.com # Please use your real domain
  password: chang3m3!

References:

• Mailu Kubernetes Setup
• Mailu Helm Chart Documentation

Functionality Test

• IMAP Sending and Receiving test

Webmail

Thunderbird Mail Client

• POP3 Sending and Receiving Test

Conclusion

There you have deployed a mail server based on a container environment. Now, you have a mail server that has been engaged with future DevOps environments. If you have further questions regarding this tutorial, freely put the questions in the comment section below.

Check other tutorials that might benefit you on our knowledge base,

The post Deploy Mailu on Rancher Kubernetes appeared first on ServerStadium.

So many S3 Client applications can be used; in this article, we will discuss three ways to manage ServerStadium Storage based on the tools and OS variants.

GUI S3 Client on Windows OS

Several S3 client applications offer S3 management using a GUI (Graphical User Interface). One of the most popular, easy-to-use, and open-source is Cyberduck.

A brief explanation of Cyberduck

Cyberduck provides full operational convenience in connecting to ServerStadium Storage. The Cyberduck application is used as an S3 client and can also be a client for FTP, SFTP, WebDAV, Dropbox, Google Drive, and many others.

There are many things we can do in CyberDuck, including:

• Add & Remove buckets
• Upload, download, and sync files
• Integrating with other programs we use to edit files (depending on file extension, eg: .txt)
• Edit permissions (ACL) for each file, and folder, up to the bucket level
• Edit Metadata for each file
• Duplicate files, folders, up to bucket level
• Monitor our file transfer process
• Create bookmarks for our other storage accounts (if any) and reconnect without having to enter their credential details every time

And we can do many other unique & advanced features, such as scheduling backups (using Duck CLI), and mounting the S3 into our Windows OS (using Mountain Duck).

Currently, Cyberduck is compatible with Windows OS and macOS.

How-To

The steps to install and operate CyberDuck are as follows:

Download Cyberduck at https://cyberduck.io and install it according to your operating system.

↳ If so, open the CyberDuck application. To establish a connection to ServerStadium Storage, click the Open Connection button.

↳ In the dialog box that appears, fill in according to the example above. For “Access Key ID” and “Secret Access Key”, you can customize your own. If so, click Connect.

↳ If it is successful, then our Object Storage will be connected and display the buckets that we have. We can upload files into the ServerStadium Storage service bucket by dragging & dropping the files that we want to upload.

↳ We can do some features to our files, folders, or buckets.

↳ You can edit files directly (on the go) without downloading the file first.

CLI S3 Client on Linux OS (Ubuntu)

Next, manage ServerStadium Storage using the CLI (Command Line Interface). Like S3 tools that use GUI, many parties develop CLI-based S3 tools. One of the most popular is the S3CMD tool.

A brief explanation of S3CMD

S3CMD is an Open Source tool that is free for personal and commercial use. Today, most cloud/sysadmins use S3CMD to manage S3 buckets. S3CMD is written in Python.

S3CMD comes with many features and options, including:

• Over 60+ command-line options
• Encryption
• Incremental Backup
• S3 sync
• Support multipart uploads
• ACLs and metadata management
• Check the size of the S3 bucket, and many others

How-To

S3CMD repositories are, by default, installed for CentOS, RHEL, and Ubuntu Systems. This tutorial will teach us the simple steps to install S3CMD on Linux (Ubuntu) and operate S3CMD to manage ServerStadium Cloud Storage.

Run the S3CMD installation using the following command:

# sudo apt-get install s3cmd

If so, now we configure S3CMD to be able to manage our Cloud Storage buckets. Type the following command:

# s3cmd --configure

↳ There will be some perimeters that we have to fill. We will need ServerStadium Cloud Storage credentials (Access Key and Secret Key).

Once the configuration is complete, let’s use the S3CMD command line to perform some activities on our ServerStadium Cloud Storage service.

1. View all of our bucket lists

# s3cmd ls

2. View the list of contents in our bucket

# s3cmd ls s3://bucket-name

3. Create a new bucket

# s3cmd mb s3://new-bucket-name

4. Upload files to the bucket (private)

# s3cmd put myfile.txt s3://my-bucket-name/myfile.txt

5. Upload files to the bucket (public)

# s3cmd put --acl-public --guess-mime-type myfile.txt s3://my-bucket-name/myfile.txt

6. Download files on the bucket

# s3cmd get s3://my-bucket-name/myfile.txt myfile.txt

7. Delete files on the bucket

# s3cmd del s3://my-bucket-name/myfile.txt

8. Delete the bucket

# s3cmd rb s3://my-bucket-name/

9. Synchronize files on our local (source) with our S3 bucket (destination)

# s3cmd sync my-local-folder-path/ s3://my-bucket-name/

10. Synchronize files on our S3 bucket (source) with our local (destination)

# s3cmd sync s3://my-bucket-name/ my-local-folder-path/

11. Do a dry-run (doesn’t do the actual activities but only displays information on what the process will do [download or upload] without actually doing it). In this tutorial, we will try the dry-run synchronization process.

# s3cmd --dry-run sync s3://my-bucket-name/ my-local-folder-path/

Those are the most frequently used commands in S3CMD, where there are download, upload, delete, and sync. We can explore and develop many more commands, one of which is by using scheduled sync combined with cron-jobs.

For other commands, you can explore in command help:

# s3cmd --help

Mobile S3 Client on Android OS

The final method we will discuss in this tutorial is accessing and managing ServerStadium Cloud Storage via Mobile S3 Client (Android). This method will be very suitable for those who want to synchronize and back up our archived data on a Mobile Phone.

The Android app that we use in this discussion is BucketAnywhere for S3. One of the reasons is that it is stable, and there have been no problems or bugs that we have found.

A brief explanation of BucketAnywhere for S3

BucketAnywhere for S3 is a file manager for Android devices. This application allows us to manage multiple S3 buckets from an Object Storage service provider compliant with the S3 REST API, which ServerStadium Cloud Storage uses.

The features provided are quite complete and no less interesting than the two tools we discussed earlier, including:

• Upload, download, delete, rename, and copy files
• Edit permissions (ACL) of each file, up to bucket level
• Create bookmarks for our other S3 accounts (if any) and reconnect without having to enter their credential details (Server URL, Access Key ID, Secret Access Key)
• Support resume (continue) unfinished download process
• Server-side encryption support
• Support for sharing S3 files with a custom expiration date

If we need file synchronization features (remote/local mirrors, scheduling, and widgets) without ads, we can grab the Pro version for around $4.49.

How-To

The steps to install and operate BucketAnywhere are as follows:

Download BucketAnywhere on PlayStore, or via the following link.

↳ The initial dashboard of BucketAnywhere is as follows. We can add a new connection by clicking Add.

↳ We will be taken to a menu for our S3 Bucket settings. There are 3 tab menus that we can configure here. The main perimeter is in the General tab, which you can fill in as follows:

• S3 URL: Fill in ServerStadium Cloud Storage URL
• KeyID : Fill in the KeyID you have in your account
• SecretKey : Fill in the SecretKey you have in your account
• Bucket : Fill in the name of your bucket in Storage Raya that you want to manage
• Local dir : The location on the mobile phone that you use to save files or sync with your Storage Raya bucket
• Resume: We can check if we want to resume the unfinished file download process from the bucket

↳ The configuration on the Advanced menu is an advanced feature that you can adjust depending on your needs.

↳ You can use the Sync tab if you are using the Pro version, where you can synchronize files (remote/local mirrors, scheduling, and widgets) in this menu. If so, you can click Save.

↳ Now connect your bucket by clicking Connect.

Conclusion

All in all, ServerStadium Cloud Storage can be managed in various ways using S3 Client Applications. This S3 Client Applications include GUI S3 Client on Windows OS using Cyberduck, CLI S3 Client using S3 CMD, and Mobile S3 Client on Android OS using BucketAnywhere for S3. Each way can be done easily without any hassle.

Find more tutorials in ServerStadium’s knowledge base.

The post Managing ServerStadium Storage from various tools and from various OS appeared first on ServerStadium.

Well, because NextCloud has a very large and wide potential in its use, then in this tutorial, let’s discuss one of the potentials that NextCloud can give us. And, of course, this is a game changer for all of you in seeing and using NextCloud in the future.

Yes, we will talk about configuring S3 Object Storage from ServerStadium so that it can be integrated with our NextCloud service in the VM.

The Benefits

By configuring S3 Object Storage on the NextCloud server, we will get a lot of advantages in terms of storage space.

As we know, by default, NextCloud will use the storage space of our VM as a place to store its files.

By binding NextCloud with S3 object storage, you don’t have to worry about running out of storage space on your VM.

Because basically, the NextCloud system doesn’t need a VM specification that is too big, but the only problem is the storage space.

What’s more, this configuration will also separate your content that is in the VM from your content that is in S3 Object Storage. So if our VM goes down for whatever reason, at least you still have access to your S3 bucket.

This is one of the benefits that I think is very good!

Prerequisites

OK, let’s move on to the implementation.

Before we get into the discussion, there are a few things you should do:

1. Have a ServerStadium VM that has NextCloud installed in it. If you don’t know how to install NextCloud in a ServerStadium VM, you can check the following tutorial.
2. Have Object Storage service in ServerStadium and have created the bucket. If you are not familiar with the S3 Object Storage service from ServerStadium, you can also check the following tutorial.

Implementation

↳ First of all, access your NextCloud dashboard. Make sure you are logged in as an admin.

↳ On the “user icon”, click Apps

↳ Then in the search field, type “External storage”, after which several results will be displayed.

↳ In the External storage support result, change it to enable

Okay, now we are ready to add external storage to our NextCloud. According to this tutorial, we will connect ServerStadium with NextCloud.

↳ Now click on the user icon again, then click on Settings.

↳ On the left menu, select External storages in the “Administration” section. Later the configuration page will appear.

↳ In the “Folder Name” field, enter a name for this external storage directory in NextCloud.

↳ Select Amazon S3, In the “External Storage” dropdown.

For those who are still wondering why we choose Amazon S3, so, ServerStadium itself is an S3-compatible Object Storage service. And by default, NextCloud connects to the Amazon Object Storage service. However, we can still override this by inputting the host from ServerStadium instead.

↳ OK, if so, in the “Authentication” dropdown, select the Access key.

↳ Finally, in the “Configuration” field, enter the following fields:

• Under “Bucket”, enter the name of the bucket from ServerStadium you created.
  
• Under “Hostname”, enter the hostname of ServerStadium. To see it, you can check the link in the “Endpoint” section on your ServerStadium page.
• Under “Port”, enter 443.
• In “Region”, enter the region of your ServerStadium storage, to find out you can enter the subdomain of this hostname, which is s3-jak01 in this example.
• Under “Enable SSL”, check this option.
• For other checks, leave the defaults.

↳ In “Access Key” and “Secret Key”, enter according to the one in your ServerStadium storage panel.

↳ There is also a field to determine whether this bucket will be shared with certain NextCloud users or available for all users. If you have your own preferences, you can enter the user or group here.

↳ If so, click on the Check icon on the right to save the configuration.

↳ If all the configurations you entered are valid, then you will see a green checkbox appear next to the entry.

OK, the configuration is complete; now let’s check the results.

↳ On the top menu, click on the Files menu item.

↳ The external storage folder that we created earlier will appear in our account’s NextCloud folder list.

↳ Let’s try clicking on the folder to see its contents. But there shouldn’t be any contents because our bucket is still empty. Unless you have uploaded certain files in this bucket in the ServerStadium panel before.

Now let’s test whether this external storage is really synchronized with our bucket.

↳ Let’s try uploading the file.

↳ Okay, it’s been uploaded; now let’s check the bucket on the ServerStadium dashboard.

↳ And it is synchronized.

Conclusion

Okay, that’s it, everyone, in this tutorial, we’ve both learned about the use of nextcloud extension because the nextcloud provides a lot of additional integrations that we can do in it.

Now by combining S3 with nextcloud, you no longer need to worry about storage space that is limited by the storage size of the NextCloud VM, and you are free to upload and delete files according to your needs because ServerStadium already carries a pay-per-use method as well. So you pay per hour according to the size of the files you have.

Find more insight on our knowledge base page for tutorials and technology updates!

The post Binding NextCloud with ServerStadium S3 Object Storage as External Storage Mount appeared first on ServerStadium.

On Ubuntu 22.04:

 sudo apt update
 sudo apt install monit -y
 sudo systemctl enable monit --now

Example config:

check filesystem root with path /dev/sda1
    if space usage > 90% for 5 cycles then alert

Mailserver config example using Gmail in /etc/monit/monitrc:

set mailserver smtp.gmail.com port 587
    username "your-username" password "12-digit-app-password"
    using tlsv13
    with timeout 30 seconds

set alert your-username+alerting@gmail.com

Then reload Monit:

 sudo monit reload

Introduction

Monit is a utility to monitor your services, systems, and processes and can handle alarms. Not only that, monit is available on most official upstream repositories. Its lightweight web user interface allows you to review the monitored components in a simple visual representation.

So, in this article, I will show you how to install Monit, monitor things, and set the alerting for them as well. This time, I will use a Ubuntu 22.04 VM instance.

Installation Steps

Step 1. Do a repository update and install Monit:

sudo apt update
sudo apt install monit -y

Step 2. Start monit service and enable it

sudo systemctl enable monit --now

Step 3. Open the /etc/monit/monitrc file, then find the following lines and uncomment them to enable the Web UI (specify the SSL cert path if you have one):

set httpd port 2812 and
    use address localhost  
    allow localhost        
    allow admin:monit

Step 4. Reload monit.

sudo monit reload

Step 5. Test it by issuing sudo monit status, it should output something like this:

You can access the Web UI by tunneling port 2812 to any free local port on your PC/Laptop.

Monitoring things

Monit can monitor a variety of things, for instance:

• Monitor websites using HTTP or HTTPS protocol
• Monitor TCP ports
• Monitor remote hosts
• Monitor popular protocols like SMTP, FTP, LDAP, etc.
• Monitor SSL certificates
• Monitor processes
• Monitor files, directories, and disks
• Monitor network interfaces
• Monitor a program’s output
• Etc.

This time, I’ll show an example of monitoring a remote host and local disk usage.

Monitor a remote host

Step 1. Go to /etc/monit/conf.d and create a new file. The name could be anything, but for example, name it simply “host”

Step 2. Edit the file with the following content:

check host myhost with address IP-ADDRESS
    if failed ping then alert

It means that we monitor a host at the specified IP-ADDRESS, and if it can’t be pinged, then send an alert. Pretty straightforward, right?

Step 3. Do a sudo monit reload to allow Monit to reload its configurations without stopping the service.

Step 4. Check the monitoring using sudo monit status myhost

Monitor a local disk

Step 1. Create a new config file in /etc/monit/conf.d and name it a “disk”

Step 2. Fill in the file with the following configuration. You may change the disk to your actual disk path:

check filesystem root with path /dev/sda1
    if space usage > 90% then alert

Step 3. Reload monit: sudo monit reload

Step 4. Verify the monitor: sudo monit status root

Configure email alerting

Step 1. Open /etc/monit/monitrc

Step 2. Add the following lines and adjust the data accordingly

set maileserver your.smtp-server.com port the-port
    username "username" password "password"
    using tls 

set alert alert-recipient@example.com

However, if you only have a public mailing service like Gmail for instance, you can use the following configuration:

set mailserver smtp.gmail.com port 587
    username "username-without-atgmailcom" password "the-password"
    using tls
    with timeout 30 seconds

set alert alert-recipient@example.com

Step 3. Test the alert by simply reloading the Monit. Example email:

You can change the alerting format in the monitrc file; try looking around at the config.

Additional Notes

For more examples of how to add other monitoring types, please visit Monit’s official documentation here: https://mmonit.com/monit/documentation/monit.html

Conclusion

It’s so easy to install and configure Monit and monitor things.

Find more tips and tutorials article in ServerStadium’s Knowledge Base. Even better, you can register in ServerStadium and try our powerful VM.

The post Simple monitoring and alerting with Monit on Ubuntu 22.04 LTS appeared first on ServerStadium.

sudo useradd -m -G sudo -s /bin/bash devel
sudo passwd devel
sudo su - devel
# as devel user #
curl -fsSL https://code-server.dev/install.sh | sudo sh
systemctl enable --now code-server@$USER

Access the VS Code via SSH Tunnel on 8080:127.0.0.1:8080, then open your browser. Enjoy!

Introduction

Did you know that you can have your very own VS Code server that can be accessed anywhere on your browser? This way, your development environment is no longer dependent on your device. And If you have a low-end PC/Mac/Laptop, running VS Code locally will burden your machine and will run very slowly.

So, let’s jump into it!

Preparation

In this article, the VS Code server will be running locally on the server. So, by default, public access is not available. So how would you access it? You can choose any of the following options:

1. Using an SSH tunnel.
2. Using a reverse proxy with basic HTTP authentication.
3. Using ServerStadium’s VPN or your own VPN server.

I will only explain the first option.

System requirements

The official minimal system requirements are:

• 1 GB of RAM
• 2 vCPUs

You can use any Linux distribution of your choice, but I will show you how to deploy it on an Ubuntu server.

Installation Steps

Step 1. Log in to your server. Assuming it’s a freshly deployed server, always update the packages.

Step 2. Create a new user. Let’s call it devel and set a password for it. Also, make sure it’s a sudoer.

# useradd -m -G sudo -s /bin/bash devel
# passwd devel

Step 3. As the devel user (and from now on), install code-server by running the following command:

curl -fsSL https://code-server.dev/install.sh | sudo sh

Step 4. Start the code-server service and enable it on boot.

sudo systemctl enable --now code-server@$USER

Step 5. Ensure it’s running by doing the following command:

ss -tulpn | grep 8080

Step 6. Open ~/.config/code-server/config.yaml to get the login password.

Step 7. Done.

Accessing via SSH Tunnel

Step 1. Ensure the SSH port (default is 22) is accessible from your network.

Step 2a. On a Linux/Mac workstation, do the following :

• Open your terminal.
• Type the below command:

ssh -N -L anyport:127.0.0.1:8080 devel@your-server-ip 

• The anyport is literally any port you wish as long as it’s not being used. Port 8000 for example.
• The command will seem to do nothing, but that is how it works. The tunnel is being established.

Step 2b. On a Windows workstation, do as follows:

• Download and Install PuTTY
• Start PuTTY, fill in your server IP address/hostname:

• Then go to Connection > SSH > Tunnels
• On the Source port define your desired port, any port as long as it’s not being used yet. And in the Destination box, type 127.0.0.1:8080. And finally, click Add.

• Go back to the Session menu, give a name for the session and click Save. This way you can directly connect to this configuration in the future easily.

• Lastly, click Open to establish the tunnel.

Step 3. Open your browser and type localhost:theport replacing theport with the port, you previously defined when establishing the tunnel.

Step 4. Put the password as you can find it in the file, then click Submit.

Step 5. Happy coding!

Last words

If you wish to access it using a dedicated domain/subdomain you own (e.g. code.example.com), check out my other article on Nginx Reverse Proxy. That way, you can proxy and secure your VS Code server using SSL.

The only thing you’ll need to change is the bind IP configuration in the ~/.config/code-server/config.yaml then change it to your LAN IP (accessible from the NPM server).

Conclusion

Installing VS Code (code-server) on a VM instance is so easy. Simply by running a designated oneliner command, it’s installed!

Check other articles in our Knowledge Base Or even better, you can try installing VS Code on ServerStadium’s VM by registering here.

The post VS Code on your browser! How to install code-server on a VM appeared first on ServerStadium.

Redis is an open-source, in-memory, key-value data store most commonly used as a primary database, cache, message broker, and queue. Redis delivers sub-millisecond response times, enabling fast and powerful real-time applications in industries such as gaming, fintech, ad-tech, social media, healthcare, and IoT.

ARCHITECTURE

The Infrastructure layout of Redis multi-cluster is like the picture below.

The initial setup will need three instances that act as the Redis master-slave.

One instance acts as the master, and the rest instances will act as the slave that replicates the data from the Redis master.

The Redis sentinel monitoring on each instance will accommodate the high availability component.

The Redis sentinel will then change the Redis configuration and determine which instance stands as master or slave.

By default, only the Redis master can read and write, whereas the slave instances can only do the read command.

STEPS

Spin Up New VMs

NOTE: The setup below is the setup used in the tutorial. Please adjust the resources based on the price you are affordable to spend.

Machine Tuning

Disabling THP on each machine

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Enabling overcommit_memory

$ echo 1 > /proc/sys/vm/overcommit_memory
## Set it persistently
$ echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf

Set swappiness at the least weight

$ echo 1 > /proc/sys/vm/swappiness
## Set it persistently
$ echo 'vm.swappiness = 1' >> /etc/sysctl.conf

Install Redis on The Related Machine

Add the repository to the apt index, update it, and then install it.

curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list

sudo apt-get update
sudo apt-get install redis redis-sentinel

Obtain Secondary Private IP and Attached it to the Redis Master

• Navigate to your Redis Master machine from the ServerStadium portal
• Click the Public & Private IP tab, then attempt to Acquire New Private IP

• Manually attach the new acquired private IP to the VM

~# ip addr add 10.10.90.92/24 dev <your interface name>
~# ip addr add 10.10.90.50/24 dev <your interface name>

Configure Redis Server

Add/overwrite the following config to your initial /etc/redis/redis.conf master

bind 127.0.0.1 <private IP>
protected-mode no

# add authentication feature for security
requirepass <your password> 

# will be used to authenticate to master during failover
masterauth <your password> 
masteruser <authoritative user> 

# enable AOF feature
appendonly yes

Add / overwrite the following config to your initial /etc/redis/redis.conf slaves

bind 127.0.0.1 <private IP>
protected-mode no

# will replicate the state from the master instance
replicaof <master ip> <master port>

# add authentication feature for security
requirepass <your password> 

# will be used to authenticate to master during failover
masterauth <your password> 
masteruser <authoritative user> 

# enable AOF feature
appendonly yes

When done, restart your Redis service on each instance.

systemctl restart redis

Config ACL to Set The Authoritative Redis User

Login to your Redis instance using the Redis-CLI command and do the AUTH using the previous password that has been set.

redis-cli -p 6379
127.0.0.1:6379> AUTH default <redis password>

## Example of the ACL
ACL SETUSER admin on allchannels >R3plicationP4sswd ~* &* +@all

## write config to the file
CONFIG REWRITE

Make sure the above ACLs are set to each Redis instance.

Configure Redis Sentinel

Add / overwrite the following config to your initial /etc/redis/sentinel.conf instances

protected-mode no
sentinel monitor mymaster <master IP> 6379 2

# Example seconds threshold to perform failover
sentinel down-after-milliseconds mymaster 15000
sentinel failover-timeout mymaster 30000

# Example of redis sentinel authentication
sentinel auth-pass mymaster R3plicationP4sswd
sentinel auth-user mymaster admin

When done, restart your Redis-sentinel service on each instance.

systemctl restart redis-sentinel

Configure Haproxy to Actively Check Redis Auto-Failover Process

Install Haproxy on Redis master node

~# apt-get install haproxy -y

Add the following setup to Haproxy Config

listen stats
        bind *:8080
        stats enable
        stats hide-version
        stats refresh 30s
        stats show-node
        stats auth appadmin:Asdf1234
        stats uri /stats


# redis block start

defaults REDIS
        mode tcp
        timeout connect 3s
        timeout server 30s
        timeout client 30s

frontend front_redis_master
        bind 10.10.90.92:6379 name redis
        default_backend back_redis_master

frontend front_redis_slave
        bind 10.10.90.50:6379 name redis
        default_backend back_redis_slave

backend back_redis_master
        option tcp-check
        tcp-check connect
        tcp-check send AUTH\ admin\ R3plicationP4sswd\r\n
        tcp-check send PING\r\n
        tcp-check expect string +PONG
        tcp-check send info\ replication\r\n
        tcp-check expect string role:master
        tcp-check send QUIT\r\n
        tcp-check expect string +OK

        server redis-a 10.10.90.37:6379 check inter 1s
        server redis-b 10.10.90.227:6379 check inter 1s
        server redis-c 10.10.90.147:6379 check inter 1s

backend back_redis_slave
        option tcp-check
        tcp-check connect
        tcp-check send AUTH\ admin\ R3plicationP4sswd\r\n
        tcp-check send PING\r\n
        tcp-check expect string +PONG
        tcp-check send info\ replication\r\n
        tcp-check expect string role:slave
        tcp-check send QUIT\r\n
        tcp-check expect string +OK

        server redis-a 10.10.90.37:6379 check inter 1s
        server redis-b 10.10.90.227:6379 check inter 1s
        server redis-c 10.10.90.147:6379 check inter 1s


# redis block end

Save the configuration and restart the Haproxy service

systemctl restart haproxy

Failover Test

The failover test section is fulfilled by purposely stopping the Redis service on the master instance.

As an expected result, the Redis sentinel will change the config on the Redis master and promote one of the slaves as the new master.

The picture below is a Haproxy TCP-check result against the Redis master and the Redis slave role.

During the master promotion, the previous master instance will turn yellow (warning alert), and the successfully promoted instance will turn green.

The picture above shows the Redis instance successfully promoted to master. The Redis-c is expected to be down because the service was stopped intentionally and has not started yet.

The Redis instance C will be promoted to a slave as soon as the Redis service is started.

CONCLUSION

We have learned how to implement Redis HA and Auto-Failover in ServerStadium. Find more tech tutorials and informative articles in ServerStadium’s Knowledge Base Or, even better, you can go to ServerStadium’s Cloud Services to get started!

The post Implementing Redis HA and Auto-Failover on ServerStadium appeared first on ServerStadium.

When we create a VM with Linux OS inside ServerStadium Cloud, it will always be CUI (Command User Interface) / terminal.

As a server, we will work more with remote systems. Indeed, a server generally does not need a GUI Desktop Environment installed because it can be managed with SSH. But if the server we are installing is a LAMP Server (Linux-Apache-MySQL-PHP, including Python and PostgreSQL) then it is very helpful to install the Desktop Environment as well. So, we can browse to find information (such as forgetting how to manage log files on Ubuntu, testing on our server, or even when we want to experience multimedia features like we usually can in the Desktop Environment).

Thus, I will explain installing the XFCE Desktop Environment in our Ubuntu VM on ServerStadium Cloud and how to connect it using Remote Desktop Connection.

What is XFCE?

To start, let’s get to know what is XFCE. XFCE is a lightweight Desktop Environment for UNIX-like operating systems. It targets a Desktop Environment that is fast and low on system resources while remaining visually appealing and user-friendly.

XFCE Features

Now, let’s jump on the features. XFCE contains several core components for the minimum tasks you’d expect from a desktop environment:

• Window & Desktop Manager
  Switch between opened windows, provide window decorations, and set Background images, and icons on the Desktop.
• Session Manager
  Controls login and power management from the Desktop and allows us to save multiple login sessions.
• Application Finder
  Shows the applications installed on the system in the form of categories so that we can quickly find and launch them.
• File Manager
  Provides basic file management features and unique utilities like bulk renamer.
• Settings Manager
  Tools to control the various settings of the desktop; like keyboard shortcuts, appearance, display settings, etc.

Besides the basic set of modules, XFCE also provides numerous additional applications and plugins so you can extend your desktop the way you like, for example, a terminal emulator, text editor, sound mixer, application finder, image viewer, iCal-based calendar and a CD and DVD burning application. You can read more about the modules of XFCE on the projects page.

The Benefits of Using XFCE

There are several impacts and benefits that we can get when using XFCE, including:

• Can access Linux VM not only via SSH but also via GUI.
• Not only can you use a Linux VM to configure the server, but it can also be used as a means of multimedia, browsing, file management, games, and other common things in the Desktop Environment.
• Get the Desktop Environment experience with its lightweight performance.
• Get the Desktop Environment experience without additional licenses, like when we use Windows OS.

Why Should we Launch XFCE on ServerStadium Cloud?

Now that we know the features and benefits of using XFCE. Let’s dive deeper into why we should launch XFCE on ServerStadium Cloud.

• Fast performance thanks to ServerStadium’s Data Center grade SSD, making our Desktop Environment fast and lightweight
• Diverse package options, making us free to determine the VM specifications that suit our Desktop Environment needs
• Flexibility in upgrading and downgrading VM specifications. Suitable for those of us who need to adjust VM performance from time to time
• Diverse cloud region options
• Reliable 24/7/365 ServerStadium’s support

Install XFCE on Ubuntu VM on ServerStadium

So, to start with, we need a VM inside ServerStadium. In this article, I will use the Ubuntu OS.

To see how easy it is to launch a VM in ServerStadium, you can check the following article: Create VM on ServerStadium

We access the VM via PuTTY.

First of all, we need to change the password to make it easier for us to access the remote desktop.

# sudo passwd root

Then we update and upgrade our Ubuntu package first.

# sudo apt-get update && apt-get upgrade

After the system is up-to-date, we can start installing the Desktop Environment. In this article, I will install Xubuntu-Desktop.

# sudo apt install xubuntu-desktop

Several other Desktop Environment options are available, such as KDE, GNOME, etc. But I’d go with XFCE because it’s light enough and fast enough; it also works well.

After everything is done, the next thing we will do is install XRDP.

XRDP provides a graphical login to remote machines using RDP (Microsoft Remote Desktop Protocol)

Most people prefer to use VNC to do remote work on their servers. However, I prefer RDP, so I will use XRDP.

# sudo apt install xrdp

When finished, we will make this XRDP service run automatically at bootup

# systemctl enable --now xrdp

This way, in the future, when we start the VM, the XRDP service will automatically run.

We can check the status also with the following command:

# systemctl status xrdp

Finally, we will create a file called xsession

# nano ~/.xsession

Add the following syntax:

xfce4-session

Conclusion

All in all, XFCE helps us to create a desktop environment of our ServerStadium Linux server VM, which by default only uses the Command User Interface. In this article, you have known XFCE’s benefits, and features, and how to install it in ServerStadium’s VM. Hopefully, you find this article helpful.

Find more tutorials and articles in ServerStadium’s Knowledge Base 

……………..

The post Using XFCE Desktop Environment on ServerStadium VM appeared first on ServerStadium.