Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

Monday 16 October 2017

Locales cosmetics. Kali on Raspberry Pi

After installation of the Kali Linux on a Raspberry Pi platform (at least in the Kali GNU/Linux Rolling) I noticed that the Xfce login screen shows in the upper right corner the full list of local keyboards installed (the locales). I don't like it! :) I don't need other than C and US keyboard and more than that, you can save some precious space on the Raspberry Pi storage.

The following post is purely cosmetic. There is no problem with the default installation despite the huge and not necessary keyboard list.

So, let's free some space!

1. First, after login (shell or X), run in console:
locale -a (Display a list of all available locales)
or
locale -a -v (As above but the -v option causes the LC_IDENTIFICATION metadata about each locale to be included in the output)


2. Make sure the file /etc/default/locale exists (if not, create it) and has proper content, such as:
LANG="en_US"
LANGUAGE="en_US:en"
or only
LANG=C.UTF-8

3. Delete all (but C.UTF-8 and en_US.utf8) generated locale data:
rm -rfv /usr/lib/locale/*

Generate again the new locales:
locale-gen

4. Restart the Pi or stop/start the X service:
service lightdm stop
service lightdm start


Of course, if you need more keyboards (or something different than US) you can in the step 3.

Wednesday 13 September 2017

rc.local issue and init.d scripts


Well, the only issue with rc.local file is that this file does not exist in modern Debian flavors.
For the old fashion guys like me that is an issue, at least for ten minutes. :)

So, what can we do about? We have at least two options:
To forgot about rc.local and start your task using init.d scripts, or
To enable the rc.local script.

Both ways have pluses and minuses and is up to you what way you will choose. For myself, I prefer the first way. Yes, it's a little bit strange to make a script for each task you will run at boot but you have a better granularity and control over the process.

Nevertheless, one way or another, following the next steps you will have a script that run on boot (or in rcS.d, or in rcX.d) :)

The first option:


Making init.d scripts, copy and paste this code and do the modifications in the start, stop sections. Save it to /etc/init.d/ folder and set the executions rights (chmod +x /etc/init.d/your-script-name).

#! /bin/sh
### BEGIN INIT INFO
# Provides:          your-script-name
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO

# Some scripts that run always (it is not mandatory...)
touch /var/lock/your_script

# Carry out specific functions when asked to by the system
case "$1" in
 start)
    echo "Starting script your-script-name"
    echo "Some info about..."
    /usr/local/bin/your-script #of course, this is an example
    ;;
 stop)
    echo "Stopping script your-script-name"
    echo "Some info about..."
    killall -9 your-script #of course, this is an example
    ;;
 restart)
    $0 stop
    $0 start
    ;;
 *)
    echo "Usage: /etc/init.d/your-script-name {start|stop|restart}"
    exit 1
    ;;
esac

exit 0

##################### End script

# Adding the init.d script to default targets (in this case to level 2,3,4, and 5, see the script headers)
root@linuxhorizon:~# update-rc.d your-script-name defaults

# Removing
root@linuxhoriozn:/etc/rc2.d# update-rc.d -f your-script-name remove



The second option:


Making the rc.local script

root@linuxhorizon:~# cat > /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/put/your/script/here

exit 0
############### End rc.local

root@linuxhorizon:~# chmod +x /etc/rc.local
root@linuxhorizon:~# systemctl start rc-local
root@linuxhorizon:~# systemctl status rc-local



Now it's a good time for a coffee! :) By the way, do you know how it look the caffeine molecule? Probably you don't, so here it is, click to enlarge!

Thursday 21 April 2016

Linux-in-the-middle - Linux box as transparent bridge

The linux box as transparent bridge

Sometime we can not mirror a switch port in order to access the data that are traveled on the wire... In this case how can we listen the data traffic? You can install a hub but on modern networks hubs that can sustain actual traffic speed is hard or even impossible to find.

So, what is the solution?
Well, the might Linux is here to help you. Of course, you need a laptop or another device (Raspberry PI?!?) with at least 3 network interfaces.


Actually, we will transform the linux box into a bridge

Before setting the bridge interface with brctl you should install the tools contained by bridge-utils package.

For debian like distros all you have to do is:

As root: apt-get install bridge-utils


This is a bridge script. Notice that only eth1 and eth2 interfaces are include into the bridge. The eth0 is left for it's usual purpose.

#!/bin/bash

/etc/init.d/networking stop

#Initializing bridge and interfaces

ifconfig br0 down
ifconfig eth1 down
ifconfig eth2 down
brctl delif br0 eth1
brctl delif br0 eth2
brctl delbr br0

sleep 1
echo "Bridge should be empty by now..."
brctl show
echo
echo
#Starting the bridge

echo "Bridge construction started..."
ifconfig eth1 0.0.0.0 up
ifconfig eth2 0.0.0.0 up
brctl addbr br0
brctl addif br0 eth1
brctl addif br0 eth2
brctl stp br0 off
echo "Bridge rised!"
echo "1" > /proc/sys/net/ipv4/ip_forward
ifconfig br0 up
brctl show
brctl showstp br0
brctl showmacs br0

# END script

Now all you can do is to interconnect your linux box in the middle of a network connection as follows (for ASCII art fans):

+----------------+     +--------------+     +-------------+
|                |     |              |     |             |
| Local network  +-----+  Linux box   +-----+ Workstation |
|                |     |              |     |             |
+----------------+     +--------------+     +-------------+


The bridge is transparent and you should not worry about what interface (we are talking only about eth1 and eth2) should be connected to the workstation or to the local network.

Now, you can dig into the network traffic listening the br0 interface... The tcpdump will show his magic. :)