2019-09-19 16:46:26 +00:00
<!DOCTYPE html>
2019-09-20 14:50:49 +00:00
<!-- vim: set ts=2 sw=2 et tw=120: -->
2019-09-19 16:46:26 +00:00
< html >
2019-09-20 14:50:49 +00:00
< head >
< meta charset = "utf-8" >
< title > maggicl - Atelier INF (blog)< / title >
< meta name = "author" content = "Claudio Maggioni (maggicl@usi.ch)" >
< link href = "https://stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css"
rel="stylesheet">
< link href = "https://fonts.googleapis.com/css?family=Fira+Sans&display=swap"
rel="stylesheet">
< link href = "css/main.css" rel = "stylesheet" >
< / head >
< body >
< header >
< h1 > < code > maggicl< / code > - Atelier INF< / h1 >
< / header >
< div class = "content" >
< nav >
< ul >
< li > < a href = "index.html" > Home< / a > < / li >
< li > < a href = "blog.html" > Blog< / a > < / li >
< li > < a href = "3d_print_service.html" > 3D prints< / a > < / li >
2019-09-22 20:35:24 +00:00
< li > < a href = "gallery.html" > Gallery< / a > < / li >
2019-09-20 14:50:49 +00:00
< / ul >
< / nav >
< main >
< article >
< section class = "title" >
< h2 > How to rickroll people that try to run "rm -rf" on your system< / h2 >
< h4 > Jul 28, 2016 -- < a class = "author" href = "index.html" data-me > Claudio Maggioni< / a > < / h4 >
< / section >
< section >
2019-09-21 12:39:28 +00:00
< figure class = "img" >
2019-09-20 16:21:34 +00:00
< figcaption > My Spotify with a bunch of Rick Astley songs< / figcaption >
2019-09-21 12:39:28 +00:00
< a href = "img/blog/spotify_rickastley.png" >
< img src = "img/blog/spotify_rickastley.png"
alt="My Spotify with a bunch of Rick Astley songs">
< / a >
2019-09-20 16:21:34 +00:00
< / figure >
< p >
2019-09-20 14:50:49 +00:00
< strong >
WARNING: The method showed here could not prevent the actual execution of "rm -rf"
if the "UNIX vandal" is clever enough. Proceed at your own risk, and make backups!
< / strong >
2019-09-20 16:21:34 +00:00
< / p >
2019-09-19 16:46:26 +00:00
2019-09-20 14:50:49 +00:00
< p >
I like Rick Astley late 80's songs, and you can see them here in my Spotify:
< / p >
2019-09-19 16:46:26 +00:00
2019-09-20 14:50:49 +00:00
< p >
I like rickrolling people too, especially if they are trying to delete my entire
< code > /home< / code > directory or, even worse, < code > /< / code > . Since I learned
how to use the < code > alias< / code > built-in, I wanted a way to prevent that
random people tinkering with my laptop (that I may forgot to lock) could
delete potentially important stuff, just for fun or boredom.
< / p >
< p >
The method that I will show will lock any < code > rm< / code > command runned in
both recursive and force mode, so < code > rm -rf< / code > , < code > rm -f -r< / code >
and < code > rm -r --force< / code > are all blocked, even if they are runned with
< code > sudo< / code > . I am going to alias the rm command in
< code > /etc/profile< / code > , < code > /etc/bash.bashrc< / code > and in
< code > /etc/zsh/zshrc< / code > (I am a zsh user) so that the rickroll will be
possible from all users, even root and the ones with a brand new
< code > .bashrc< / code > or < code > .zshrc< / code > . Here is the code I appended to
those files:
< / p >
2019-09-20 16:21:34 +00:00
< figure class = "right" >
2019-09-20 14:50:49 +00:00
< figcaption > < em > Alias< / em > code to use to activate < code > rmAlias< / code > < / figcaption >
< pre > alias rm=/bin/rmAlias
alias sudo='sudo '
# this enables aliases in sudo, see
# http://askubuntu.com/questions/22037< / pre >
< / figure >
< p >
Since < code > alias< / code > is not able to control the flags of the aliases (see
< a href = "http://apple.stackexchange.com/questions/50963/" > here< / a > , we are going
to redirect each call of < code > rm< / code > to
< code > /bin/rmAlias< / code > , that would run the command if it is safe. I did
not use a function because it is a bit tricky to make that work with
< code > sudo< / code > . So, let's see the code I put in < code > rmAlias< / code > :
< / p >
< figure >
< figcaption > Code for < code > rmAlias< / code > < / figcaption >
< pre >
#! /bin/bash
# Rickroll whoever tries to desert this system, even root.
# To achieve this, set the appropriate aliases even in
# /etc/profile and similars.
# Video played when rickrolling
ROLLVIDEO=/opt/anti-rm/serious-video.mkv
# it's just Never Gonna Give You Up on my system, but
# feel free to customize this!
rickroll(){
echo "Never gonna desert this system..."
xdg-open $ROLLVIDEO 2>& 1 &
exit 0
}
while getopts ":rf-" opt; do
# Prevent '--force' to be detected as -r and -f
if [ "$opt" = "-" ]; then
OPTIND=$OPTIND+1
continue
fi
if [ "$opt" = "r" ] || [ "$opt" = "f" ]; then
if [ "$tmp" = "" ]; then
tmp=$opt
continue
elif [ "$tmp" != "$opt" ]; then
rickroll
fi
fi
done
for var in "$@"
do
if [[ "$var" = "--force" & & "$tmp" = "r" ]]; then
rickroll
fi
done
# If it's safe, just run rm
/bin/rm "$@"
exit $?< / pre >
< / figure >
< p >
It may look messy to a < em > UNIX< / em > guy more experienced than me, but it
works. The < code > getopts< / code > built-in sees if both the < code > -r< / code > and
the < code > -f< / code > flags are used and, if so, it starts
< code > rickroll()< / code > , which opens with < code > xdg-open< / code > that amazing
clip from < em > RickAstleyVEVO< / em > . From line 30 and below, the script checks
if the < code > --force< / code > flag is used instead of < code > -f< / code > .
< / p >
< p >
Let's give execution permissions to the script we have just created:
< / p >
2019-09-20 16:21:34 +00:00
< figure class = "right" >
2019-09-20 14:50:49 +00:00
< figcaption > Giving execution permissions of < code > rmAlias< / code > < / figcaption >
< pre >
# chmod +x /bin/rmAlias< / pre >
< / figure >
< p >
Restart your shell, and enjoy. If you want to test safely, I suggest trying
to run < code > rm -rf< / code > with no folders or a nonexistant one, since this
script stops even these commands.
< / p >
< p >
If you want even more security, you can rename this script to
< code > /bin/rm< / code > and move the original one in some other place, getting rid
of all the aliases. I prefer the solution above because it's tidier: you
haven't to move anything. In fact, this could be just an AUR package...
< / p >
< / section >
< / article >
< article >
< section class = "title" >
< h2 > Installing Gentoo on a Lenovo ThinkPad X60s< / h2 >
< h4 > Jul 12, 2016 -- < a class = "author" href = "index.html" data-me > Claudio Maggioni< / a > < / h4 >
< / section >
< section >
2019-09-21 12:39:28 +00:00
< figure class = "img" >
2019-09-20 16:21:34 +00:00
< figcaption > The < em > X60s< / em > < / figcaption >
2019-09-21 12:39:28 +00:00
< a href = "img/blog/thinkpad1.jpg" >
< img src = "img/blog/thinkpad1.jpg" alt = "An image of the ThinkPad X60s" >
< / a >
2019-09-20 16:21:34 +00:00
< / figure >
2019-09-20 14:50:49 +00:00
< p > Currently, my only laptop is a
< a href = "http://www.thinkwiki.org/wiki/Category:X60s" > IBM/Lenovo ThinkPad
X60s< / a > , a top line < em > ultrabook< / em > from 2006 that features:
< / p >
< ul >
< li > An Intel Core Duo L2400 dual core 32 bit CPU, clocked at 1.66 Ghz;< / li >
< li > 2GB of RAM;< / li >
< li > 60GB of SATA1 hard drive;< / li >
< li > Wifi, Bluetooth, trackpoint mouse only, 56k modem, and a decent set of
I/0 ports (including a CardBus slot!).< / li >
< / ul >
2019-09-19 16:46:26 +00:00
2019-09-21 12:39:28 +00:00
< figure class = "right img" >
2019-09-20 16:21:34 +00:00
< figcaption > The < em > X60s< / em > one more time< / figcaption >
2019-09-21 12:39:28 +00:00
< a href = "img/blog/thinkpad2.jpg" >
< img src = "img/blog/thinkpad2.jpg" alt = "Another image of the ThinkPad X60s" >
< / a >
2019-09-20 14:50:49 +00:00
< / figure >
< p >
This machine had an installation on < em > Arch Linux< / em > , and I was using it
for school stuff. It runned smoothly < em > KDE5< / em > , < em > Atom< / em > (great
editor, I am using it to write this article), and it was usable even with
< em > PhpStorm< / em > . Pretty impressive for such an old thing, right?
< / p >
< p >
Since now I don't need this laptop every day I decided to give a try
at Gentoo,
another rolling relase, DIY install distro. This was both a test of my
skills, my patience and the performances of the machine. For those of you
that don't know, Gentoo hasn't binary packages: imagine using Arch with just
a developer mantained AUR.
< / p >
< p >
I followed the < a href = "https://wiki.gentoo.org/wiki/Handbook:Main_Page" >
installation guide< / a > without any problem until I had to < em > emerge< / em >
and install 309 packets from my < code > @world< / code > set: it took 15 hours!
The compilation of < code > cmake< / code > crashed because of memory starvation,
and so I had to use a spare USB stick as swap (the root file system was not
resizable as it was JFS). After some research and a couple of seconds in
< code > top< / code > I discovered that
< a href = "https://en.wikipedia.org/wiki/Physical_Address_Extension" > PAE< / a >
was not implemented in the install disk kernel. < strong > TIP:< / strong > if you
want to use a nicer install enviroment, use the < em > Arch< / em > ISO. With
< em > Gentoo< / em > , the initialisation of the file system is made with a
< a href = "https://wiki.gentoo.org/wiki/Stage_tarball#Stage_3" > < em > stage 3
tarball< / em > < / a > and not by tools like
< a href = "https://wiki.archlinux.org/index.php/beginners'_guide#Install_the_base_packages" >
< code > pacstrap< / code > < / a > .
< / p >
< p >
I had another problem with < code > make menuconfig< / code > , the tool used to
specify what features add or remove in your compiled from source Linux kernel.
The < code > ncurses< / code > menu showed me 64bit options, even if the install
disk and the CPU were both 32 bit. If you have this issue too, you can set
the < code > ARCH< / code > variable by your own:
< / p >
< figure >
< figcaption > Compiling the kernel< / figcaption >
< pre > # make ARCH=i386 menuconfig
# make ARCH=i386
# make ARCH=i386 install< / pre >
< / figure >
< p >
At the end, I made it! I only have a base install, but i can show you
< code > screenfetch< / code > :
< / p >
2019-09-21 12:39:28 +00:00
< figure class = "img" >
2019-09-20 14:50:49 +00:00
< figcaption > The laptop running < em > screenfetch< / em > < / figcaption >
2019-09-21 12:39:28 +00:00
< a href = "img/blog/screenfetch.jpg" >
< img src = "img/blog/screenfetch.jpg" alt = "The laptop running 'screenfetch'" >
< / a >
2019-09-20 14:50:49 +00:00
< / figure >
< p >
I have not installed < em > Gentoo< / em > in dual boot because I did not figure
out how to switch my bluetooth dongle in HID mode yet, so I can't select
the OS with < code > rEFInd< / code > . Hope this rambling was, if not useful,
at least entertaining!
< / p >
< / section >
< / article >
< article >
< section class = "title" >
< h2 > Get a Bluetooth keyboard work with Arch Linux< / h2 >
< h4 > Jul 7, 2016 -- < a class = "author" href = "index.html" data-me > Claudio Maggioni< / a > < / h4 >
< / section >
< section >
2019-09-21 12:39:28 +00:00
< figure class = "img" >
< figcaption > The keyboard in question< / figcaption >
< a href = "img/blog/rapoo.jpg" >
< img src = "img/blog/rapoo.jpg" alt = "The keyboard in question" >
< / a >
< / figure >
2019-09-20 14:50:49 +00:00
< p >
I've recently got a Rapoo E6100. This is a minimal and space saving Bluetooth
3.0 keyboard. If you pair it with Windows 10, it will remain paired after
reboot, giving the possibility to use it since the login screen. After
installing the Bluetooth stack on my Arch via the < code > bluez< / code > and
< code > bluez-utils< / code > packages I thought the pairing process would be as
simple as Windows if I used the KDE GUI menus for Bluetooth management. That's
not true. The keyboard, once paired, will reconnect automatically just after
< code > plasmashell< / code > loaded, leaving me without keyboard during the SDDM
login screen and, of course, during a non-graphical session.
< / p >
< p >
As usual, i've searched help in the ArchWiki, founding
< a href = "https://wiki.archlinux.org/index.php/Bluetooth_keyboard" > this< / a >
article. With that, i've succesfully reconnected my Bluetooth keyboard using
the < code > bluetoothctl< / code > utility. The next step was configuring the
service for auto connection during boot. I've created the
< code > btkbd.conf< / code > and the < code > btkbd.service< / code > files, enabling
the last one with systemd. Let's give a look to the service file:
< / p >
2019-09-22 20:35:24 +00:00
< figure class = "right" >
2019-09-20 14:50:49 +00:00
< figcaption > The < code > btkbd.service< / code > file< / figcaption >
< pre > [Unit]
Description=systemd Unit to automatically start a \
Bluetooth keyboard
Documentation=archwiki: Bluetooth_Keyboard
Requires=dbus-org.bluez.service
After=dbus-org.bluez.service
ConditionPathExists=/etc/btkbd.conf
ConditionPathExists=/usr/bin/hcitool
ConditionPathExists=/usr/bin/hciconfig
[Service]
Type=oneshot
EnvironmentFile=/etc/btkbd.conf
ExecStart=/usr/bin/hciconfig ${HCIDEVICE} up
# ignore errors on connect, spurious problems with bt?
# so start next command with -
ExecStart=-/usr/bin/hcitool cc ${BTKBDMAC}
[Install]
WantedBy=multi-user.target< / pre >
< / figure >
< p >
Line 13 enables the Bluetooth dongle, and line 16 connects it to the keyboard we gave the mac address in < code > /etc/btkbd.conf< / code > . This should work flawlessly, right? Of course it doesn't. The service starts before the < code > dbus-org.bluez.service< / code > is loaded and fails. However, if the service is started manually after login the Bluetooth keyboard works. After hours of trying figuring out what was wrong I've almost asked for a return on Amazon! The last attempt I made was with sddm disabled and involved built from scratch service:
< / p >
2019-09-20 16:21:34 +00:00
< figure class = "right" >
2019-09-20 14:50:49 +00:00
< figcaption > My service file< / figcaption >
< pre > [Unit]
Description=auto connect a Bluetooth keyboard
[Service]
Type=oneshot
ExecStart=/bin/hciconfig hci0 up
ExecStart=/bin/hcitool cc 00:11:22:33:44:55
[Install]
WantedBy=bluetooth.target< / pre >
< / figure >
< p >
This incredibly worked. I think the problem was that < code > multi-user.target< / code > that needs to be reached earlier than < code > bluetooth.target< / code > . I got rid of all the tidiness of the ArchWiki solution just to be sure that was not the problem, but I think you can use all of that just correcting < code > WantedBy=< / code > . Currently I haven't an ArchWiki account nor a forum one, but as soon as I'll register I'll correct the article.
< / p >
< p >
Last thing: I discovered that my Bluetooth dongle is CSR 8510 A10 based so expect some ramblings about < a href = "http://www.0xf8.org/2014/02/the-crux-of-finding-a-hid-proxy-capable-usb-bluetooth-adapter/" > hid proxy< / a > .
< / p >
< / section >
< / article >
< / main >
< aside >
< ul >
< li > < a href = "https://reddit.com/u/Praticamentetilde" >
< i class = "fa fa-reddit" aria-hidden = "true" > < / i > Praticamentetilde
< / a > < / li >
< / ul >
< / aside >
< / div >
< footer xmlns:dct = "http://purl.org/dc/terms/"
xmlns:vcard="http://www.w3.org/2001/vcard-rdf/3.0#">
< a rel = "license"
href="http://creativecommons.org/publicdomain/zero/1.0/">
< img width = "88" height = "31"
src="http://i.creativecommons.org/p/zero/1.0/88x31.png"
alt="CC0" />
< / a >
< section >
< p > To the extent possible under law,
< span resource = "[_:publisher]" rel = "dct:publisher" >
< span property = "dct:title" > Claudio Maggioni< / span > < / span >
has waived all copyright and related or neighboring rights to
< span property = "dct:title" > SA3 AS1 Website< / span > .
This work is published from:
< span property = "vcard:Country" datatype = "dct:ISO3166"
content="CH" about="[_:publisher]">
Switzerland< / span > .
< / p >
2019-09-22 20:35:24 +00:00
< p > Page last updated on 2019-09-22< / p >
2019-09-20 14:50:49 +00:00
< / section >
< / footer >
< / body >
< / html >
