DEV Community: shema-surge

Errors as values (Go)

shema-surge — Tue, 15 Apr 2025 18:42:10 +0000

How Go's error handling is better

In programming languages like java and javascript, errors are special. They are handled using fancy syntax like try and catch statements but often end up becoming messy and confusing.

Here is an example a file copying program written in javascript:

const fs = require("node:fs")
const { argv } = require("node:process")
try {
    const data = fs.readFileSync(argv[2], "utf-8")
    fs.writeFileSync(argv[3],data)
} catch (err) {
    console.error(err)
}

In the above program we try to read a text file whose name is provided as an stdin argument to the program and write its contents to a second file whose name is also provided as the second argument

> node copy.js file1.txt file2.txt

The problem with this program is that if it crashed, we would not know where the error occurred from. Would it be from the readFileSync function or writeFileSync? In this scenario we are left to speculate about where error could have been thrown.

We could try and handle errors using callbacks for Example:

fs.readFile(argv[2], "utf-8",(err, data)=>{
    if (err){
        console.error(err)
    }
    fs.writeFile(argv[3], data, err=>{
       if (err){
        console.error(err)
       }
    })
})

but this approach quickly leads to callback hell when working with multiple risky functions.

However when it comes to Go, we are forced to think about the errors returned on each step of the way. Here is the same program now written Go.

package main

import (
    "log"
    "os"
)

func main() {
    data, readErr := os.ReadFile(os.Args[1])
    if readErr != nil {
        //do something with the read error
        log.Fatal(readErr)
    }
    writeErr := os.WriteFile(os.Args[2], data, 0600)
    if writeErr != nil {
        //do something with the write error
        log.Fatal(writeErr)
    }
}

In Go, we handle errors like any other value. This provides clarity into where the errors are coming from and how to handle them.

The DIY Movement

shema-surge — Tue, 02 Apr 2024 16:20:51 +0000

The DIY movement is a movement of self-sufficiency. It's core tenet and goal is literally in it's name "Do it yourself".

If every person had the ability to build their own house, fix their own car, write their own operating system and make their own beer, the world would be a significantly better place. we wouldn't need giant polluting factories to mass-produce useless products when people can produce all of their material needs on an individual scale.

This movement has made some significant strides in recent times, 3D printing is one of many examples of technologies that allow people to make their own tools and objects instead of relying on industrial manufacturing. This movement promises a future of abundance and freedom from corporations that destroy human ingenuity.

The only limiting factor is the availability of knowledge. People can't make things without guides and manuals. With the modern internet getting bloated with paywalls and human knowledge getting swallowed up by an avalanche of useless social media content and AI generated articles, A platform that democratizes knowledge would help ensure that the DIY movement does not die out.

How to create a simple high availability apache webserver cluster

shema-surge — Sun, 23 Apr 2023 10:16:25 +0000

A high availability (HA) cluster is a group of interconnected computers, servers or nodes, that work together to ensure that an application or service remains available even if one or more of the nodes in the cluster fails. The primary goal of an HA cluster is to provide continuous availability and minimize downtime by distributing the workload across multiple nodes.

In an HA cluster, each node is responsible for a specific task, and if one node fails, another node in the cluster takes over that task automatically.

This article assumes that you have setup two identical centos vms or physical machines, each running apache web servers that host the same website. In this article, node1 has ip address 192.168.1.2/24 and node2 has 192.168.1.3/24.

ON BOTH NODES

yum install ricci luci ccs cman modcluster cluster* -y

start the ricci service

service ricci start

set a password for ricci user on both nodes

passwd ricci

IN THE MASTER NODE

create the cluster

ccs -h 192.168.1.2 --createcluster mycluster

add nodes to the cluster

ccs -h 192.168.1.2 --addnode 192.168.1.2
ccs -h 192.168.1.2 --addnode 192.168.1.3

ccs -h 192.168.1.2 --lsnodes lists all nodes added in the cluster

Add Fencing to Cluster

Fencing is the disconnection of a node from shared storage. Fencing cuts off I/O from shared storage, thus ensuring data integrity.

ccs -h 192.168.1.2 --setfencedaemon post_fail_delay=0
ccs -h 192.168.1.2 --setfencedaemon post_join_delay=0

Create a fence device

A fence device is a hardware device that can be used to cut a node off from shared storage.

A fence agent is a software program that connects to a fence device in order to ask the fence device to cut off access to a node’s shared storage (via powering off the node or removing access to the shared storage by other means).

There are different types of fencing devices available. If you are using virtual machine to build a cluster, use fence_virt device as shown below.

ccs -h 192.168.1.2 --addfencedev myfence agent=fence_virt

create fence method and add nodes to it

ccs -h 192.168.1.2 --addmethod mymethod 192.168.1.2
ccs -h 192.168.1.2 --addethod mymethod 192.168.1.3

add fence method to fence device

ccs -h 192.168.1.2 --addfenceinst myfence 192.168.1.2 mymethod

css -h 192.168.1.2 --addfenceinst myfence 192.168.1.3 mymethod

create a failover domain

A failover domain is an ordered subset of cluster members to which a resource group or service may be bound.

ccs -h 192.168.1.2 --addfailoverdomain mywebserverdomain ordered

add both nodes to the failover domain

ccs -h 192.168.1.2 --addfailoverdomainnode mywebserverdomain 192.168.1.2 1

ccs -h 192.168.1.2 --addfailoverdomainnode mywebserverdomain 192.168.1.3 2

ccs -h 192.168.1.2 --lsfailoverdomain shows the nodes and their priorities

add apache webserver service to the cluster setup

ccs -h 192.168.1.2 --addservice apache domain=mywebserverdomain recovery=relocate autostart=1

sync cluster configurations across all cluster nodes

ccs -h 192.168.1.2 --sync --activate

check cluster configuration

ccs -h 192.168.1.2 --checkconf

OUTPUT: All nodes in sync

Disable NetworkManager on all nodes because it stops cman service from starting

service NetworkManager stop
chkconfig NetworkManager off

start the cman service on all nodes

service cman start

use clustat to check status of all cluster nodes

clustat

OUTPUT

Cluster Status for mycluster @ Fri Apr 21 14:00:22

Member Status: Quorate

Member Name             ID   Status
------ ----             ---- ------
192.168.1.2                    1 Online, Local
192.168.1.3                2 Online

TESTING CLUSTER NODES

bring down a node

ccs -h 192.168.1.3 --stop

Do clustat to check status of all nodes

OUTPUT

Cluster Status for mycluster @ Fri Apr 21 14:00:22

Member Status: Inquorate

Member Name             ID   Status
------ ----             ---- ------
192.168.1.2                1 Online, Local
192.168.1.3                2 Offline

On the node that is down, clustat give an error saying: "Could not connect to CMAN: No such file or directory"

start the offline node

ccs -h 192.168.1.3 --start

THE END

Setup a simple DNS server in CentOS

shema-surge — Mon, 10 Apr 2023 14:28:47 +0000

Let's Begin with a simple question,

WHAT IS DNS?

DNS (Domain Name System) is like a phonebook for the internet. It is very difficult to remember the phone number of all your contacts but it is easy to remember their names.
To make calling people easier, a phonebook matches your contact's name or alias to their phone number so that you don't have to remember their numbers.

Same goes for the internet, it is easy to remember the domain name of a website like https://dev.to than it is to remember its IP address. But computers do not recognize each other on a network using domain names, they use IP adresses. Therefore, the primary role of the DNS is to translate a domain name to an IP address.

For a more detailed explanation of how DNS works, checkout this link https://www.cloudflare.com/learning/dns/what-is-dns/

We will be using bind, a suite of software for interacting with DNS

Step 1: Login as root

su

Step 2: Install Bind

BIND (Berkeley Internet Name Domain) is the most widely used DNS (Domain Name System) server software on the Internet. It is an open-source implementation of the DNS protocol, originally developed at the University of California, Berkeley, and now maintained by the Internet Systems Consortium.



yum install bind bind-utils -y

Step 3: Change ip address to static

After installing bind, we will change the dynamically allocated ip address to a static one, 192.168.1.2/24.

To do this, edit the ifcfg file for your network interface (enp0s3 or eth0 or ....):

Note: Network interfaces can vary in naming, my centos came with enp0s3 so i'll stick with it.



vim /etc/sysconfig/network-scripts/ifcfg-enp0s3

Now, we'll add the ip address,network mask, and a default gateway and a DNS server address:



IPADDR=192.168.1.2
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
DNS1=192.168.1.2

Notice that the DNS i gave it matches the ip address of the server such that it can query itself.

Now edit BOOTPROTO and change it from dhcp to none,since we no longer optain an ip address from a dhcpd server.



BOOTPROTO=none

After that, we'll need to restart NetworkManager



systemctl restart NetworkManager

and bing up our network interface



ifup enp0s3

To test if it works ping yourself



ping 192.168.1.2

Step 4: DNS Configuration

First, we'll edit the named.conf file



vim /etc/named.conf

in the vim editor do :set number to show line numbers

In the options section on line 13, add your the server ip address to the list of ip addresses bind listens to.

listen-on port 53 {127.0.0.1; 192.168.1.2; };

And add the 192.168.1.0/24 subnet to the list of ip addresses allowed to query our DNS on line 21:

allow-query {localhost; 192.168.1.0/24; };

Now all clients with an ip address in 192.168.1.0/24 subnet can query our DNS

After line 57, add the following lines,



zone "example.com" {
    type master;
    file "forward.example.zone";
    allow-update {none;};
};

This specifies our domain to be example.com, type master signifies that the DNS Server has autority over this zone and can allow or block queries to this zone

forward.example.zone is a forward zone file for example.com, it contains information that allows the DNS to resolve example.com to 192.168.1.2

Now we'll create the forward zone file for example.com,



cp /var/named/named.localhost /var/named/forward.example.zone

change the forward zone file's group to named group



chgrp named /var/named/forward.example.zone

Now edit your forward zone file,



vim /var/named/forward.example.com

NOTE: please remember to end every domain name with a "." in the zone file, or else you'll get errors.

To check if the named.conf file does not have errors,



named-checkconf /etc/named.conf

No output means there are not errors.

To check if the zone file is correctly configured,



named-checkzone example.com /var/named/forward.example.com

When the output says zone example.com/IN: loaded serial 0, OK, then it was configured correctly.

Note: named-checkzone takes the domain specified in the /etc/named.conf file as a parameter.

Now we'll need to restart named.service



systemctl restart named.service

Step5: testing our DNS

nslookup is a command-line tool used to query the Domain Name System (DNS) to obtain information about DNS records for a specific domain name or IP address



nslookup example.com

The output should like this,

dig command-line tool is used to query DNS servers to obtain information about domain names, IP addresses, and DNS records. "dig" is short for "domain information groper".



dig example.com

The above command should provide details about the DNS Server

I hope you learnt something, until next time.

Writing custom middleware functions in NodeJS

shema-surge — Tue, 12 Jul 2022 19:19:03 +0000

Middleware is any code that runs on the server between getting a request and a response. Middleware functions in NodeJS have access to the request object, the response object and the next function.

function middleFunc(req,res,next){
    req.message:'Hello'
    next()
}

In the example above, the function middleFunc is a middleware function that takes three parameters: req,res,and next. The function sets a req.message to 'Hello'.

Middleware functions do not end the request-response cycle but they have to call next() to either pass execution to the next middleware function or the request handler itself. If next() function is not called, the request will hang.

A middleware function can be run by passing it between the path and callback function of the request handler.

app.get('/',middleFunc,(req,res)=>{
    res.json(req.message)
})

Here, middleFunc will run first then when next() is called, the execution is passed to the request handler which prints the message.

It is also possible to rewrite the middleware function as an Application-level middleware like this,

app.use((req,res,next)=>{
    req.message = 'Hello'
    next()
})