Linux is a beautiful example of clean engineering. Form follows function and function follows coherent thoughts. The following is a collection of notes.
To add a sudo user that doesn't have a password you have to first add a user with a password, and then delete the password. This activates the password.
sudo adduser usernameyoulike # give the user any temp password # the following command removes the password sudo passwd -d usernameyoulike # add the user to the sudoers list usermod -aG sudo usernameyoulike
I fell in a deep rabbit hole with udev whilst building Primo. Here is a
comprehensive guide about udev link.
To get all the information about a USB device:
udevadm info -a -p $(udevadm info -q path -n /dev/video1)
Some commands have changed since the bible has been written.
To test, you can use the test function of udevadm. Problem is that you have to give
it the top level device path in sysfs. For example, an arduino plugged into
Primo and showing up as ttyACM1, this was
/sys/bus/usb/devices/1-6. To find the top level device path, use the
command above and substitute in the port name.
To test an Arduino:
udevadm test /sys/bus/usb/devices/1-6
To restart the udev system:
sudo udevadm control --reload-rules && udevadm trigger
You will still need to unplug/replug stuff!! Or do a reboot.
Some pitfalls I came across. You cannot change device names! You can only add symlinks to them. The symlink did not work for the Tara uvc_camera. I think this is issue has to do with the fact that the Tara has some weird shit with the way the USB host onboard handles the two cameras.
Here's some other commands:
Lists the possible device attribute keys and their values along with the parents of the device.
udevadm info --attribute-walk /dev/bus/usb/<bus_num>/<device_num>
Lists the device attributes and their values.
udevadm info -a /dev/video0
Reload udev rules
udevadm control --reload-rules && udevadm trigger
To get info on hidraw devices:
cat /sys/class/hidraw/hidraw2/device/uevent
# Arduino with Encoder code
# For some readon the serial thingy doesn't work
# SSUBSYSTEMS=="usb", ATTRS{iSerial}=="5563930383435181B021", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0043", SYMLINK+="ard-enc
# SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0043", ATTRS{idSerial}=="Arduino_Srl_Arduino_Uno_5563930383435181B021", SYMLINK+="ard-enc"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0043", SYMLINK+="ard_enc", MODE="0666"
# Add a symlink to the stereo camera. This doesn't work with seecam's driver and you
# need to reference the device ID.
When doing lsusb, use sudo!! If you don't, you won't be able to see devices whose
permissions haven't been properly set.
Shows the USB version of the devices with that vendor id:
sudo lsusb -v | grep 2560 -A 10 | grep bcdUSB
Cron is used to automate the running of jobs.
I use it to run a backup script and a VimWiki html generate script.
To add a job to cron you must edit the crontab file. You do this by running the following command:
crontab -e
This will load up the default editor (you can change this to be vim by running export EDITOR=vim) and open the crontab file.
Cron has an interesting way of setting up timing intervals, look this up online. Here's some examples:
# Run every minute *\1 * * * * ~/paul_scripts/update_wiki_html.sh # Run on the 45th minute of every hour 45 * * * * ~/paul_scripts/cronjob.sh
To check the cron logs, type the following:
grep CRON /var/log/syslog
This will show you what jobs where run last. Cron discards the output of these jobs if no MTA is setup, and don't worry about this.
I use the XFCE display manager because it was the only one that allowed my laptop dock and 2 external monitor system to work properly.
Set the number of rows in the workspace to 2. That way you get a nice grid.
I use the xfce4-terminal. I have all nicely setup with a config file
that resides in ~/.config/xfce4/terminal.
To move windows around we need the following packages.
sudo apt-get install xdotool sudo apt-get install wmctrl
Get the move window script from storage. Add following keyboard shortcut application commands:
<CTRL><ALT><SUPER><LEFT Arrow> : /home/paul/paul_scripts/move-to-next-monitor -l <CTRL><ALT><SUPER><RIGHT Arrow> : /home/paul/paul_scripts/move-to-next-monitor -r
This information was gathered from here.
I use taskwarrior and timewarrior as a task keeping daily
Use pre-built debians for both taskmanager and timewarrior. You have to copy a file to get taskwarrior to use timewarrior.
cp /usr/share/doc/timewarrior/ext/on-modify.timewarrior ~/.task/hooks
I have tried every remote desktop option I could find. The best solution in terms of ease of use, performance, and reliability has been TeamViewer. In any case here's a bunch of notes of ones I've tried.
Using default VNC server on Linux machine. Using xvnc4viewer (RealVNC viewer) on xubuntu (xfce) desktop.
using the x11 VNC server on the server. Port 5900 and 5901.
Running into security issues with the VNC server stuff. Tried:
VNC-Server:
Viewer:
I keep getting “Server did not offer supported security type”.
Trying out the RealVNC server and viewer. Installing RealVNC on Primo using wget and a Debian pkg. Gave up on installing RealVNC because you need the premium version for headless operation which is what I have.
The server that worked was this:
sudo x11vnc -xkb -noxrecord -noxfixes -noxdamage -display :0 -auth /var/run/lightdm/root/:0 -usepw
Issue is getting the x11vnc server to load before a login has occurred, which is what makes all this VNC shit complicated.
I used vncviewer on the client computer to talk to it.
Problem is that it is slow. I don't think there is anything we can do it. It is also slow through the LAN. I've attributed this issue to running headless.
I ran into a bunch of issues by running the Primo computer headless, meaning without a display attached to it. The first time I noticed this was when I ran the computer without a display attached to it. It would run extremely slow when trying to remote into it. I then would plug in a display and bam, everything would run nice and fast.
The reason for this is because without a display attached, the onboard GPU does not properly initialize. Everything relating to graphics becomes slow when running headless. X forwarding is slow, steaming video is slow, remote desktop with team viewer and VNC, and any remote video stuff.
To diagnose the problem we see what drivers are being used for the graphics operation.
glxinfo|egrep "OpenGL vendor|OpenGL renderer*"
If no hardware acceleration is detected, such when using a non professional grade display, a virtual driver such as this one will be detected:
OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.8, 256 bits)
To solve this problem I found the following solutions:
There are cheap dummy plugs that trick the video card into thinking that there is a display attached. TheHeadless Ghost is one of them. I bought the cheap knockoff from Amazon which worked great.
The other obvious solution is to use a display. I purchased an 800x480 TFT LCD screen with a touch screen designed for the Raspberry Pi for 40 bucks.
Here are some command line shortcuts.
To remove all files except for one in zsh:
setopt extendedglob rm -- ^file.txt
To pump out contents of file to clipboard:
sudo apt install xclip cat file | xclip -selection clipboard
This thing is awesome!
For setting up ssh keys, xclip doesn't work. Use the following:
clip.exe < ~/.ssh/id_rsa.pub
For setting up external ssh access I did the following:
Reinstall openssh for some reason:
sudo apt-get purge openssh-server sudo apt-get install openssh-server
From an elevated powershell I ran this to change the port to 2222 to not interfere with any windows services:
New-NetFirewallRule -DisplayName "Allow Inbound Port 2222" -Direction Inbound -LocalPort 2222 -Protocol TCP -Action Allow
I added the following to sshd_config:
Port 2222
PermitRootLogin no
AllowUsers paul
I created an authorized hosts file and imported the keys.
I tested the connection by running this on the server:
sudo service ssh stop sudo /usr/sbin/sshd -d
Then on the client I ran a debug version of an ssh server to see if I was receiving incoming connections.
ssh name@server -p 2222
I then monitored the server and make sure I could see the connection. The debug client quit out cause it didn't have correct paths to the keys, but the test was a success cause it validated the port pass through. I then restarted the regular service like this:
sudo service ssh start