Category: shell

how to manage airpods on linux

This article guides you on how to manage airpods and airpods pro on linux.

It uses pulseaudio and ofono telephony service for A2DP, HSP/HFP profiles.

Lets start…

1. Dependencies

Shell
1
2
3
sudo add-apt-repository ppa:smoser/bluetooth  
sudo apt-get install ofono-phonesim ofono  
git clone https://github.com/rilmodem/ofono.git /opt/ofono

2. Download the script

Shell
1
wget https://raw.githubusercontent.com/AkhilJalagam/pulseaudio-airpods/master/pulseaudio-airpods

3. Tweak the script for first time

replace MAC and card name in the script

Shell
1
2
AIRPODS_MAC='4C:6B:E8:80:46:84' # it should be somewhere in blueman-manager  
AIRPODS_NAME='bluez_card.4C_6B_E8_80_46_84' # you can find this using 'pactl list cards' command

4. Usage

Shell
1
pusleaudio-airpods connect/toggle_profile/disconnect

Note

you should first pair your airpods using blueman-manager and trust them to use this script

References

https://github.com/AkhilJalagam/pulseaudio-airpods

https://github.com/AkhilJalagam/i3blocks-airpods

Speed up SSH with multiplexing

SSH multiplexing is the ability to carry multiple SSH sessions over a single TCP connection.

OpenSSH can reuse an existing TCP connection for multiple concurrent SSH sessions. This results into reduction of the overhead of creating new TCP connections.

Advantage of using SSH multiplexing is that it speeds up certain operations that rely on or occur over SSH. For example, let’s say that you’re using SSH to regularly execute a command on a remote host. Without multiplexing, every time that command is executed your SSH client must establish a new TCP connection and a new SSH session with the remote host. With multiplexing, you can configure SSH to establish a single TCP connection that is kept alive for a specific period of time, and SSH sessions are established over that connection.

You can see the difference below

without multiplexing, we see the normal connection time:

$ time ssh lintel-blog

Then we do the same thing again, but with a multiplexed connection to see a faster result:

$ time ssh lintel-blog

Configure Multiplexing

OpenSSH client supports multiplexing its outgoing connections, since version 3.9, using the ControlMaster, ControlPath and ControlPersist configuration directives which get defined in ssh_config. The client configuration file usually defaults to the location ~/.ssh/config.

ControlMaster determines whether ssh will listen for control connections and what to do about them. ControlPath sets the location for the control socket used by the multiplexed sessions. These can be either globally or locally in ssh_config or else specified at run time. Control sockets are removed automatically when the master connection has ended. ControlPersist can be used in conjunction with ControlMaster. If ControlPersist is set to ‘yes’, then it will leave the master connection open in the background to accept new connections until either killed explicitly or closed with -O or ends at a pre-defined timeout. If ControlPersist is set to a time, then it will leave the master connection open for the designated time or until the last multiplexed session is closed, whichever is longer.

Here is a sample excerpt from ssh_config applicable for starting a multiplexed session to server1.example.org via the shortcut server1.

Shell
1
2
3
4
5
Host server1
  HostName server1.example.org
  ControlPath ~/.ssh/controlmasters/%r@%h:%p
  ControlMaster auto
  ControlPersist 10m

 

How to install jitsi meet on CentOS 7

Jitsi is a set of Open Source projects that allows you to easily build and deploy secure videoconferencing solutions.

Jitsi Meet is a fully encrypted, 100% Open Source video conferencing solution that you can use all day, every day, for free — with no account needed.

1. Architecture

A Jitsi Meet installation can be broken down into the following components:

  • A web interface
  • An XMPP server
  • A conference focus component
  • A video router (could be more than one)
  • A SIP gateway for audio calls
  • A Broadcasting Infrastructure for recording or streaming a conference.

The diagram shows a typical deployment in a host running Docker. This project separates each of the components above into interlinked containers. To this end, several container images are provided.

2. Ports

The following external ports must be opened on a firewall:

  • 80/tcp for Web UI HTTP (really just to redirect, after uncommenting ENABLE_HTTP_REDIRECT=1 in .env)
  • 443/tcp for Web UI HTTPS
  • 4443/tcp for RTP media over TCP
  • 10000/udp for RTP media over UDP

Also 20000-20050/udp for jigasi, in case you choose to deploy that to facilitate SIP access.

E.g. on a CentOS server this would be done like this (without SIP access):

 

3. Configuration

The configuration is performed via environment variables contained in a .env file. You can copy the provided env.example file as a reference.

a. Jibri Module Setup

Before running Jibri, you need to set up an ALSA loopback device on the host. This will not work on a non-Linux host.

For CentOS 7, the module is already compiled with the kernel, so just run:

b. Installation

  • clone the repository:

git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet

  • Create a .env file by copying and adjusting env.example
    • cp env.example .env
  • Set strong passwords in the security section options of .env file by running the following bash script
    • ./gen-passwords.sh
  • Create required CONFIG directories
    • mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}
  • Run docker-compose up -d
  • Access the web UI at https://domain.com (or a different port, in case you edited the compose file).

 

If you want to use jigasi too, first configure your env file with SIP credentials and then run Docker Compose as follows: docker-compose -f docker-compose.yml -f jigasi.yml up

If you want to enable document sharing via Etherpad, configure it and run Docker Compose as follows: docker-compose -f docker-compose.yml -f etherpad.yml up

If you want to use jibri too, first configure a host as described in JItsi BRoadcasting Infrastructure configuration section and then run Docker Compose as follows: docker-compose -f docker-compose.yml -f jibri.yml up -d or to use jigasi too: docker-compose -f docker-compose.yml -f jigasi.yml -f jibri.yml up -d

Running behind NAT or on a LAN environment
If running in a LAN environment (as well as on the public Internet, via NAT) is a requirement, the DOCKER_HOST_ADDRESS should be set. This way, the Videobridge will advertise the IP address of the host running Docker instead of the internal IP address that Docker assigned it, thus making ICE succeed. If your users are coming in over the Internet (and not over LAN), this will likely be your public IP address. If this is not set up correctly, calls will crash when more than two users join a meeting.

The public IP address is discovered via STUN. STUN servers can be specified with the JVB_STUN_SERVERS option.

 

Parallel command execution – Linux Cluster

The pdsh parallel shell tool allows you and lets you run a shell command across multiple nodes in a cluster.

This is a high performance, parallel pdsh shell remote shell utility for admins. Chaos Pdsh is a multithreaded remote shell client which executes commands on multiple remote hosts in parallel.  A parallel shell permits your clusters Linux Ubuntu RedHat to run the same similar command on many designated hosts or nodes within the hadoop cluster. In this case you do not have to really log in to each node individually.

High-performance and parallel remote shell utility with dshgroup module allows dsh on pdsh (or otherwise known as Dancer’s shell sudo) files from /etc/dsh/group directory. Now download Parallel Distributed Shell free of charge.

What is pdsh?

pdsh is a variant of the rsh(1) command. Unlike rsh(1), which runs commands on a single remote host, pdsh can run multiple remote commands in parallel. pdsh uses a “sliding window” (or fanout) of threads to conserve resources on the initiating host while allowing some connections to time out.

When pdsh receives SIGINT (ctrl-C), it lists the status of current threads. A second SIGINT within one second terminates the program. Pending threads may be canceled by issuing ctrl-Z within one second of ctrl-C. Pending threads are those that have not yet been initiated, or are still in the process of connecting to the remote host.

If a remote command is not specified on the command line, pdsh runs interactively, prompting for commands and executing them when terminated with a carriage return. In interactive mode, target nodes that time out on the first command are not contacted for subsequent commands, and commands prefixed with an exclamation point will be executed on the local system.

The core functionality of pdsh may be supplemented by dynamically loadable modules. The modules may provide a new connection protocol (replacing the standard rcmd(3) protocol used by rsh(1)), filtering options (e.g. removing hosts that are “down” from the target list), and/or host selection options (e.g., -a selects all hosts from a configuration file.). By default, pdsh must have at least one “rcmd” module loaded. See the RCMD MODULES section for more information.

Installing pdsh

Debian based:

apt install pdsh

RHEL based:

yum install pdsh

Running

The following command installs telegraf on all 4 nodes in cluster02

Running multiple commands

Pipe redirection

 

Example

 

When using ssh for remote execution, expect the stderr of ssh to be folded in with that of the remote command. When invoked by pdsh, it is not possible for ssh to prompt for passwords if RSA/DSA keys are configured properly, etc.. For ssh implementations that suppport a connect timeout option, pdsh attempts to use that option to enforce the timeout (e.g. -oConnectTimeout=T for OpenSSH), otherwise connect timeouts are not supported when using ssh. Finally, there is no reliable way for pdsh to ensure that remote commands are actually terminated when using a command timeout. Thus if -u is used with ssh commands may be left running on remote hosts even after timeout has killed local ssh processes.

Output from multiple processes per node may be interspersed when using qshell or mqshell rcmd modules.

The number of nodes that pdsh can simultaneously execute remote jobs on is limited by the maximum number of threads that can be created concurrently, as well as the availability of reserved ports in the rsh and qshell rcmd modules. On systems that implement Posix threads, the limit is typically defined by the constant PTHREADS_THREADS_MAX.

How to install Ansible AWX on centos 7

Ansible Tower (formerly ‘AWX’) is a web-based solution that makes Ansible even more easy to use for IT teams of all kinds. It’s designed to be the hub for all of your automation tasks.

Tower allows you to control access to who can access what, even allowing sharing of SSH credentials without someone being able to transfer those credentials. Inventory can be graphically managed or synced with a wide variety of cloud sources. It logs all of your jobs, integrates well with LDAP, and has an amazing browsable REST API. Command line tools are available for easy integration with Jenkins as well. Provisioning callbacks provide great support for autoscaling topologies.

AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is the upstream project for Tower, a commercial derivative of AWX.

Prerequisites

Before you can run a deployment, you’ll need the following installed in your local environment:

System Requirements

The system that runs the AWX service will need to satisfy the following requirements

  • At least 4GB of memory
  • At least 2 cpu cores
  • At least 20GB of space
  • Running Docker, Openshift, or Kubernetes
  • If you choose to use an external PostgreSQL database, please note that the minimum version is 10+.

Installation steps:

1. Install Dependencies

yum install -y epel-release

yum remove python-docker-py

yum install -y yum-utils device-mapper-persistent-data lvm2 ansible git python-devel python-pip python-docker-py vim-enhanced

pip install cryptography
pip install jsonschema
pip install docker-compose~=1.23.0
pip install docker –upgrade

2. Install docker

Configure docker ce stable repository.

yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

Installing docker.

yum install docker-ce -y

Start docker service.

systemctl start docker

Enable docker service.

systemctl enable docker

3. Deploy AWX

Clone AWX repo

git clone https://github.com/ansible/awx.git

Clone commercial logos

cd awx/

git clone https://github.com/ansible/awx-logos.git

Configure AWX

cd installer/

$ vim inventory

awx_official=true

Deploy AWX

ansible-playbook -i inventory install.yml -vv

Check the status

docker ps -a

AWX is ready and can be accessed from the browser.

http://ipaddress:80/

the default username is “admin” and the password is “password”.

Final checks:

  1. verify whether the service is started or not with ss -tlnp | grep 80
  2. make sure your firewall is open for port 80
  3. make sure your OS is using python 3.6+ and pip3

References:

https://github.com/ansible/awx/blob/devel/INSTALL.md

How to setup SOCKS proxy in Linux

A SOCKS server is a general purpose proxy server that establishes a TCP connection to another server on behalf of a client, then routes all the traffic back and forth between the client and the server. It works for any kind of network protocol on any port. SOCKS Version 5 adds additional support for security and UDP.

Use of SOCKS is as a circumvention tool, allowing traffic to bypass Internet filtering to access content otherwise blocked, e.g., by governments, workplaces, schools, and country-specific web services

Using SSH

SOCKS proxies can be created without any special SOCKS proxy software if you have Open SSH installed on your server and an SSH client with dynamic tunnelling support installed on your client computer.

Now, enter your password and make sure to leave the Terminal window open. You have now created a SOCKS proxy at localhost:1080. Only close this window if you wish to disable your local SOCKS proxy.

Using Microsocks program

MicroSocks is a multithreaded, small, efficient SOCKS5 server.

It’s very lightweight, and very light on resources too:

for every client, a thread with a stack size of 8KB is spawned. the main process basically doesn’t consume any resources at all.

the only limits are the amount of file descriptors and the RAM.

It’s also designed to be robust: it handles resource exhaustion gracefully by simply denying new connections, instead of calling abort() as most other programs do these days.

another plus is ease-of-use: no config file necessary, everything can be done from the command line and doesn’t even need any parameters for quick setup.

Installing microsocks

git clone git@github.com:rofl0r/microsocks.git

cd microsocks

make

Starting socks service

all arguments are optional. by default listenip is 0.0.0.0 and port 1080.

option -1 activates auth_once mode: once a specific ip address authed successfully with user/pass, it is added to a whitelist and may use the proxy without auth. this is handy for programs like firefox that don’t support user/pass auth. for it to work you’d basically make one connection with another program that supports it, and then you can use firefox too.

Howto use ssh as VPN tunnel

SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding TCP ports and X11 connections.

What is SSH Tunneling?

A tunneling protocol may, for example, allow a foreign protocol to run over a network that does not support that particular protocol, such as running IPv6 over IPv4.

SSH tunneling is a method of transporting arbitrary networking data over an encrypted SSH connection. It can be used to add encryption to legacy applications. … It also provides a way to secure the data traffic of any given application using port forwarding, basically tunneling any TCP/IP port over SSH.

sshuttle

sshuttle is not exactly a VPN, and not exactly port forwarding. It’s kind of both, and kind of neither.

It’s like a VPN, since it can forward every port on an entire network, not just ports you specify. Conveniently, it lets you use the “real” IP addresses of each host rather than faking port numbers on localhost.

On the other hand, the way it works is more like ssh port forwarding than a VPN. Normally, a VPN forwards your data one packet at a time, and doesn’t care about individual connections; ie. it’s “stateless” with respect to the traffic. sshuttle is the opposite of stateless; it tracks every single connection.

Installation

 sudo pip install sshuttle

Example

$ sshuttle --dns -v -r <remote-host> 0/0

ssh-tunnel

* This will forward all connections including DNS requests…

Usage

Shell script wrapper function for sending messages through Pushover

Pushover makes it easy to get real-time notifications on your Android, iPhone, iPad, and Desktop (Android Wear and Apple Watch, too!)

You can use this shell function anywhere in your script.

Example:

Note: you need to update API tokens and title above

Locking your bash script against parallel execution

Sometimes there’s a need to ensure only one copy of a script runs, i.e prevent two or more copies running simultaneously. Imagine an important cronjob doing something very important, which will fail or corrupt data if two copies of the called program were to run at the same time. To prevent this, a form of MUTEX (mutual exclusion) lock is needed.

The basic procedure is simple: The script checks if a specific condition (locking) is present at startup, if yes, it’s locked – the script doesn’t start.

This article describes locking with common UNIX® tools.

Method 1

setting the noclobber shell option (set -C). This will cause redirection to fail, if the file the redirection points to already exists (using diverse open() methods). Need to write a code example here.

Shell
1
2
3
4
5
6
7
8
if ( set -o noclobber; echo "locked" > "$lockfile") 2> /dev/null; then
  trap 'rm -f "$lockfile"; exit $?' INT TERM EXIT
  echo "Locking succeeded" >&2
  rm -f "$lockfile"
else
  echo "Lock failed - exit" >&2
  exit 1
fi

 

Method 2

A simple way to get that is to create a lock directory – with the mkdir command. It will:

create a given directory only if it does not exist, and set a successful exit code
it will set an unsuccessful exit code if an error occurs – for example, if the directory specified already exists
With mkdir it seems, we have our two steps in one simple operation. A (very!) simple locking code might look like this:

Shell
1
2
3
4
5
6
if mkdir /var/lock/mylock; then
  echo "Locking succeeded" >&2
else
  echo "Lock failed - exit" >&2
  exit 1
fi

In case mkdir reports an error, the script will exit at this point – the MUTEX did its job!

WSL vs WSL 2 – performance

WSL 2 is a new version of the architecture that powers the Windows Subsystem for Linux to run ELF64 Linux binaries on Windows. Its primary goals are to increase file system performance, as well as adding full system call compatibility. This new architecture changes how these Linux binaries interact with Windows and your computer’s hardware, but still provides the same user experience as in WSL 1 (the current widely available version). Individual Linux distros can be run either as a WSL 1 distro, or as a WSL 2 distro, can be upgraded or downgraded at any time, and you can run WSL 1 and WSL 2 distros side by side. WSL 2 uses an entirely new architecture that uses a real Linux kernel.

It’s a major reworking of the original WSL concept, moving away from translating Linux system calls to Windows to shipping a complete Linux kernel that runs alongside Windows’ own kernel.

The reasons for doing this are many, but the main one is simple: It’s impossible for an emulator that ships twice a year to keep up with the changes in the Linux kernel, changes that Linux binaries depend on. If Windows is to support developers building Linux apps for the cloud, then it needs to be more than consistent, it needs to be compatible.

 

Linux kernel in WSL 2

The Linux kernel in WSL 2 is built in house from the latest stable branch, based on the source available at kernel.org. This kernel has been specially tuned for WSL 2. It has been optimized for size and performance to give an amazing Linux experience on Windows and will be serviced through Windows updates, which means you will get the latest security fixes and kernel improvements without needing to manage it yourself.

Increased file IO performance

File intensive operations like git clone, npm install, apt update, apt upgrade, and more will all be noticeably faster. The actual speed increase will depend on which app you’re running and how it is interacting with the file system. Initial versions of WSL 2 run up to 20x faster compared to WSL 1 when unpacking a zipped tarball, and around 2-5x faster when using git clone, npm install and cmake on various projects.

Sockets performance benchmarks

WSL

wsl

 

WSL 2

wsl2

The Ubuntu 18.04 LTS WSL instance was used for testing with its default packages. In addition to looking at the WSL1 vs. WSL2 performance of Ubuntu 18.04, Ubuntu 18.04.2 LTS itself was also tested bare metal on the same system for looking at the raw performance of Ubuntu on the Intel desktop being tested.

Full System Call Compatibility

Linux binaries use system calls to perform many functions such as accessing files, requesting memory, creating processes, and more. In WSL 1 we created a translation layer that interprets many of these system calls and allows them to work on the Windows NT kernel. However, it’s challenging to implement all of these system calls, resulting in some apps being unable to run in WSL 1. Now that WSL 2 includes its own Linux kernel it has full system call compatibility. This introduces a whole new set of apps that you can run inside of WSL. Some exciting examples are the Linux version of Docker, as well as FUSE!

Using WSL 2 means you can also get the most recent improvements to the Linux kernel much faster than in WSL 1, as we can simply update the WSL 2 kernel rather than needing to reimplement the changes ourselves.

WSL 2 will be a much more powerful platform for you to run your Linux apps on and will empower you to do more with a Linux environment on Windows.