×


Blog


Broken trust relationship between workstation and domain - Fix it now

This article covers tips to fix the 'broken trust relationship between workstation and domain' problem.

The underlying problem when this error is seen is that the machine you are trying to access can no longer communicate securely with the Active Directory domain to which it is joined.


Method to fix The trust relationship between this workstation and the primary domain failed Windows issue:

To resolve this issue, remove the computer from the domain, and then connect the computer to the domain.

1. Use a local administrator account to log on to the computer.

2. Select Start, press and hold (or right-click) Computer > Properties.

3. Select Change settings next to the computer name.

4. On the Computer Name tab, select Change.

5. Under the Member of heading, select Workgroup, type a workgroup name, and then select OK.

6. When you are prompted to restart the computer, select OK.

7. On the Computer Name tab, select Change again.

8. Under the Member of heading, select Domain, and then type the domain name.

9. Select OK, and then type the credentials of the user who has permissions in the domain.

10. When you are prompted to restart the computer, select OK.

11. Restart the computer.


MongoDB service is not starting up - Fix it now

This article covers how to resolve the the problem of starting MongoDB server when running the command mongod which may arise due to file permission or ownership issues.


The reason was the dbpath variable in /etc/mongodb.conf. 

To fix, you only had to change the owner of the /data/db directory recursively.

Also For ubunto , what made it happen and was real simple is to install mongodb package:

$sudo apt-get install  mongodb


Also, You can use the below-mentioned command for mongodb service is not starting up:-

$sudo rm /var/lib/mongodb/mongod.lock 

$mongod --repair 

$sudo service mongodb start


Mongodb service is not starting up:

This can also happen if your file permissions get changed somehow. 

Removing the lock file didn't help, and we were getting errors in the log file like:

2016-01-20T09:14:58.210-0800 [initandlisten] warning couldn't write to / rename file /var/lib/mongodb/journal/prealloc.0: couldn't open file    /var/lib/mongodb/journal/prealloc.0 for writing errno:13 Permission denied

2016-01-20T09:14:58.288-0800 [initandlisten] couldn't open /var/lib/mongodb/local.ns errno:13 Permission denied

2016-01-20T09:14:58.288-0800 [initandlisten] error couldn't open file /var/lib/mongodb/local.ns terminating


So, went to check permissions:

ls -l /var/lib/mongodb

total 245780

drwxr-xr-x 2 mongodb mongodb     4096 Jan 20 09:14 journal

drwxr-xr-x 2 root    root        4096 Jan 20 09:11 local

-rw------- 1 root    root    67108864 Jan 20 09:11 local.0

-rw------- 1 root    root    16777216 Jan 20 09:11 local.ns

-rwxr-xr-x 1 mongodb nogroup        0 Jan 20 09:14 mongod.lock


Log Suspicious Martian Packets Un-routable Source Addresses in Linux

This article covers how to block and log suspicious martian packets on Linux servers.


Log Suspicious Martian Packets in Linux:

On the public Internet, such a packet's (Martian) source address is either spoofed, and it cannot originate as claimed, or the packet cannot be delivered. 

Both IPv4 and IPv6, martian packets have a source or destination addresses within special-use ranges as per RFC 6890.


Benefits of logging of martians packets:

As I said earlier a martian packet is a packet with a source address that cannot be routed over the public Internet. 

Such a packet is waste of resources on your server. 

Often martian and unroutable packet used for a dangerous purpose or DoS/DDOS your server. 

So you must drop bad martian packet earlier and log into your server for further inspection.


To log Martian packets on Linux?

You need to use sysctl command command to view or set Linux kernel variables that can logs packets with un-routable source addresses to the kernel log file such as /var/log/messages.


To log suspicious martian packets on Linux:

You need to set the following variables to 1 in /etc/sysctl.conf file:

net.ipv4.conf.all.log_martians

net.ipv4.conf.default.log_martians


Edit file /etc/sysctl.conf, enter:

# vi /etc/sysctl.conf

Append/edit as follows:

net.ipv4.conf.all.log_martians=1 

net.ipv4.conf.default.log_martians=1


Save and close the file.

To load changes, type:

# sysctl -p


Redirect FreeBSD Console To A Serial Port for KVM Virsh - How to do it

This article covers how to redirect FreeBSD in KVM to the serial port.

FreeBSD does support a dumb terminal on a serial port as a console.


This is useful for quick login or debug guest system problem without using ssh. 

1. First, login as root using ssh to your guest operating systems:

$ ssh ibmimedia@freebsd.ibmimedia.com

su -

2. Edit /boot/loader.conf, enter:

# vi /boot/loader.conf

3. Append the following entry:

console="comconsole"

4. Save and close the file. Edit /etc/ttys, enter:

# vi /etc/ttys

5. Find the line that read as follows:

ttyd0  "/usr/libexec/getty std.9600"   dialup  off secure

6. Update it as follows:

ttyd0   "/usr/libexec/getty std.9600"   vt100   on secure

7. Save and close the file. Reboot the guest, enter:

# reboot

8. After reboot, you can connect to FreeBSD guest as follows from host (first guest the list of running guest operating systems):

# virsh list

Sample outputs:


 Id Name                 State

----------------------------------

  3 ographics            running

  4 freebsd              running

9. Now, connect to Freebsd guest, enter:

virsh console 4

OR

virsh console freebsd


PXE Boot or DHCP Failure on Guest - Fix it now

This article covers how to fix PXE Boot (or DHCP) Failure on Guest.

Nature of this error:

A guest virtual machine starts successfully, but is then either unable to acquire an IP address from DHCP or boot using the PXE protocol, or both. There are two common causes of this error: having a long forward delay time set for the bridge, and when the iptables package and kernel do not support checksum mangling rules.


Cause of PXE BOOT (OR DHCP) ON GUEST FAILED:

Long forward delay time on bridge.

This is the most common cause of this error. If the guest network interface is connecting to a bridge device that has STP (Spanning Tree Protocol) enabled, as well as a long forward delay set, the bridge will not forward network packets from the guest virtual machine onto the bridge until at least that number of forward delay seconds have elapsed since the guest connected to the bridge. This delay allows the bridge time to watch traffic from the interface and determine the MAC addresses behind it, and prevent forwarding loops in the network topology. If the forward delay is longer than the timeout of the guest's PXE or DHCP client, then the client's operation will fail, and the guest will either fail to boot (in the case of PXE) or fail to acquire an IP address (in the case of DHCP).


Fix to PXE BOOT (OR DHCP) ON GUEST FAILED:

If this is the case, change the forward delay on the bridge to 0, or disable STP on the bridge.

This solution applies only if the bridge is not used to connect multiple networks, but just to connect multiple endpoints to a single network (the most common use case for bridges used by libvirt).


If the guest has interfaces connecting to a libvirt-managed virtual network, edit the definition for the network, and restart it. 

For example, edit the default network with the following command:

# virsh net-edit default

Add the following attributes to the <bridge> element:

<name_of_bridge='virbr0' delay='0' stp='on'/>

XML


If this problem is still not resolved, the issue may be due to a conflict between firewalld and the default libvirt network.

To fix this, stop firewalld with the service firewalld stop command, then restart libvirt with the service libvirtd restart command.


Install ClickHouse on Ubuntu 20.04 - Step by step process to perform it

This article covers how to install ClickHouse on Ubuntu. Basically, ClickHouse is an open-source analytics database developed for big data use cases. 

Install of ClickHouse on Ubuntu involves a series of steps that includes adjusting the configuration file to enable listening over other IP address and remote access. 


Column-oriented databases store records in blocks grouped by columns instead of rows. 

By not loading data for columns absent in the query, column-oriented databases spend less time reading data while completing queries. 

As a result, these databases can compute and return results much faster than traditional row-based systems for certain workloads, such as OLAP.


Online Analytics Processing (OLAP) systems allow for organizing large amounts of data and performing complex queries. 

They are capable of managing petabytes of data and returning query results quickly. 

In this way, OLAP is useful for work in areas like data science and business analytics.


Aggregation queries are queries that operate on a set of values and return single output values. 

In analytics databases, these queries are run frequently and are well optimized by the database. 


Some aggregate functions supported by ClickHouse are:

1. count: returns the count of rows matching the conditions specified.

2. sum: returns the sum of selected column values.

3. avg: returns the average of selected column values.


Some ClickHouse-specific aggregate functions include:

1. uniq: returns an approximate number of distinct rows matched.

2. topK: returns an array of the most frequent values of a specific column using an approximation algorithm.


You can set up a ClickHouse database instance on your server and create a database and table, add data, perform queries, and delete the database.

You can start, stop, and check the ClickHouse service with a few commands.

To start the clickhouse-server, use:

$ sudo systemctl start clickhouse-server

The output does not return a confirmation.

To check the ClickHouse service status, enter:

$ sudo systemctl status clickhouse-server

To stop the ClickHouse server, run this command:

$ sudo systemctl stop clickhouse-server

To enable ClickHouse on boot:

$ sudo systemctl enable clickhouse-server

To start working with ClickHouse databases, launch the ClickHouse client. 

When you start a session, the procedure is similar to other SQL management systems.

To start the client, use the command:

$ clickhouse-client