Home systems

This doc contains the things I've found I need to update to get my linux2 server working.

Changing default serial port protections

create a file, such as <code>99-local.rules</code> in the following directory: <code>/etc/udev/rules.d/</code> with the following info:

<pre>

2. Give world read/write access to ttyS* and ttyUSB* serial devices

KERNEL=="tty[A-Z]*", GROUP="uucp", MODE="0666" </pre>

Ubuntu dual monitors

Run <code>nvidia-settings</code>. Now we may need to modify the Xconf file, if so see the following:

1. Open nvidia-settings by searching for nvidia in the Dash, or run the command gksudo nvidia-settings in the Terminal. Note not to press the apply button.
2. Under 'Xserver Display Configuration' select TwinView and configure the settings for the monitors to your liking.
3. Click 'Save to X Configuration File' and an error message should appear. Click OK.
4. In the next dialog box click the button to 'Show Preview'.
5. Leave the preview window open and open a Terminal. Run the following commands in the Terminal to back up your xorg.conf file and open the original file in a test editor. If something goes wrong, just revert to your backed up xorg.conf.
6. sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.bak
7. gksudo gedit /etc/X11/xorg.conf`
8. Copy the text from the nvidia-settings preview window into the xorg.conf file. Save the xorg.conf file and close gedit. Click 'Cancel' to close the nvidia-settings preview window. Then click 'Quit' to exit completely out of nvidia-settings without applying or saving any data.
9. Restart your computer. If all went well, the two monitors should work together.

Note: As of ubuntu 12.04 you don't appear to need to copy the xorg.conf files around. Just clicking save is all it takes.

Rebuilding Raid

Rebuilding a raid system?

Detail from mdadm of good working file system prior to zeroing the superblock.

<pre> sudo mdadm --detail /dev/md4 /dev/md4:

       Version : 0.90
 Creation Time : Sat Mar 19 08:02:27 2011
    Raid Level : raid6
    Array Size : 160649856 (153.21 GiB 164.51 GB)
 Used Dev Size : 80324928 (76.60 GiB 82.25 GB)
  Raid Devices : 4
 Total Devices : 4

Preferred Minor : 4

   Persistence : Superblock is persistent

   Update Time : Sun Jun  3 21:06:27 2012
         State : clean 
Active Devices : 4

Working Devices : 4

Failed Devices : 0
 Spare Devices : 0

        Layout : left-symmetric
    Chunk Size : 64K

          UUID : b60f9401:efa1275e:6caba8f0:d8b2a7d7
        Events : 0.457

   Number   Major   Minor   RaidDevice State
      0       8       66        0      active sync   /dev/sde2
      1       8       82        1      active sync   /dev/sdf2
      2       8       98        2      active sync   /dev/sdg2
      3       8       50        3      active sync   /dev/sdd2

</pre>

Note, the drive order is very important. Also, remove the ARRAY entry from /etc/mdadm/mdadm.conf for the drive.

<pre> sudo mdadm --stop /dev/md6 sudo mdadm --zero-superblock /dev/sd[defg]2 sudo mdadm --create /dev/md6 --metadata=1.0 --chunk=64 --level=6 --raid-devices=4 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sdd2 </pre>

Ok, now we need to get the blkid from the md filesystem and add an entry into the mdadm.conf file which matches.

<pre> sudo blkid /dev/md6 # edit mdadm.conf file and add entry "ARRAY /dev/md6 UUID=dad67a5c:0907045c:7eb49ca0:d0f6f000" sudo mdadm --assemble /dev/md6 --update=resync sudo mdadm --detail /dev/md6 sudo blkid /dev/md6 sudo mount -t ext3 /dev/md6 /mnt/temp

watch -n 1 cat /proc/mdstat </pre>

or... ???

<pre> sudo mdadm --stop /dev/md6 sudo mdadm --zero-superblock /dev/sd[defg]2 sudo mdadm --create /dev/md6 --metadata=0.9 --chunk=64 --level=6 --raid-devices=4 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sdd2 sudo mdadm --assemble /dev/md6 --update=resync sudo mdadm --detail /dev/md6 sudo blkid /dev/md6 sudo mount -t ext3 /dev/md6 /mnt/temp </pre>

If this is a new raid drive, make the filesystem then mount

<pre> sudo mkfs /dev/md6 sudo mount /dev/md6 /mnt/temp </pre>

Fixing mail permission errors on linux2

Do the following: <pre> sudo touch /var/mail/$USER sudo chown $USER:mail /var/mail/$USER sudo chmod o-r /var/mail/$USER sudo chmod g+rw /var/mail/$USER </pre>

Updates to tzo configuration

After installing tzo I needed to update the <code>tzod</code> script in <code>/etc/init.d</code>. I updated the following script segment to look like this (basically just added the lines with <code>/lib/lsb...</code>: <pre> if [ -f /etc/rc.d/init.d/functions ]; then

       . /etc/rc.d/init.d/functions

elif [ -f /etc/init.d/functions ] ; then

       . /etc/init.d/functions

elif [ -f /lib/lsb/init-functions ] ; then

   . /lib/lsb/init-functions

else </pre>

Next I added a soft link in the <code>/etc/rc.5.d/</code> directory: <pre> sudo ln -s ../init.d/tzod S99tzod </pre>

Trick for port forwarding

This lets me access the CUPS system on the linux2 server from my linux laptop. Issue this command on the laptop, insert the appropriate passwords...

<pre> ssh -L 6310:localhost:631 root@remote_ip_address </pre>

Now access the cups system via the browser on the laptop by going to <code>localhost:6310</code>.

Making movies from jpg files

This seems to work...

<pre> mencoder -ovc copy -mf w=320:h=240:fps=12:type=jpg "mf://*.jpg" -o output.avi mencoder -ovc copy -mf w=320:h=240:fps=12:type=jpg "mf://@list.txt" -o output.avi </pre>

Raspberry pi serial port

http://www.raspberrypi.org/forums/viewtopic.php?&t=27035

Raspberry pi mount usb stick

sudo mkdir /temp
sudo mount /dev/sda1 /temp  -o uid=pi,gid=pi

Raspberry pi gpio

Command line:

pinctrl help
pinctrl get 26
pinctrl set 26 ip pu
pinctrl get 26

Python:

GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
GPIO.setup(pin.findValueInt("Inject"), GPIO.OUT)
GPIO.output(pin.findValueInt("Inject"), initialState)
GPIO.setup(pin.findValueInt("Button"), GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.output(p, GPIO.LOW)
GPIO.output(p, GPIO.HIGH)
b = GPIO.input(pin.findValueInt("Button"))

Backing up the server

Run the following command on the desktop which has the backup disk mounted. This will backup /home to the backup drive, and this command should be repeated for each filesystem on linux server. rsync is now enabled on the msgsb.com server.

rsync -avzH linux2:/home2 /media/mhamilton/Seagate\ Backup\ Plus\ Drive/home2/

Also this can be run on the pi at the condo. Login to the condo pi and run the following commands:

ssh pi@h-condo.dyndns.org
rsync -avzh mhamilton@msgsb.com:/home3 /backup-msgsb/home3

To setup ssh to not query for passwords, from the pi:

ssh-keygen
ssh-copy-id -i ~/.ssh/id_rsa.pub mhamilton@msgsb.com

To run the following backup command:

rsync -avzh --rsync-path="sudo rsync" rsyncuser@nextcloud:/home/rsyncuser/ /backup-nextcloud

the sudoers file on the nextcloud server must be updated with the following line added:

rsyncuser ALL=(ALL) NOPASSWD: ALL

Current implemented procedure

The nextcloud server has a user (rsyncuser) which runs a backup process every saturday night at 3am. This process is run from the script "backup.sh". It runs the nextcloud.export process which creates a backup copy of the nextcloud environment (hopefully) in a backup area within the "common/backups" folder in nextcloud environment. This backup is then moved to the location within the rsyncuser file system space.

Next the rpi runs a script sunday morning at 4am using rsync to copy the data from the rsyncuser file system to the rpi backup disk. The backup disk is currently "/dev/sdb1" partition.

At 3am the rpi runs a script to rsync the /home2,3,4 filesystems from the linux1 server to the "/dev/sda1" disk.

Latest sshd configuration changes as of ubuntu 22.04.03 lts

In /etc/ssh/sshd_config change the following lines as shown:

PubkeyAuthentication yes

PubkeyAcceptedKeyTypes=+ssh-rsa

Then restart sshd

sudo systemctl restart sshd

---

Nextcloud backup info

How to backup your instance Kyle Fazzari edited this page on Aug 7, 2019 · 7 revisions

The nextcloud snap includes an utility to backup and restore your instance. Right now it can export:

• The apps
• The database
• The config
• The raw data
• But note that this does not cover exporting other settings, like HTTPS certificates.

Export everything

Run sudo nextcloud.export and it'll turn on maintenance mode and dump a backup of your entire instance into a timestamped folder, something like 20190121-153921, inside /var/snap/nextcloud/common/backups/.

After the export is complete the snap will forget about it, so feel free to do whatever you like with it; one option could be to tar it, with a command like this:

sudo tar -cvf 20190121-153921_nextcloud-backup.tar /var/snap/nextcloud/common/backups/20190121-153921

Import everything

You can import an exported backup by running sudo nextcloud.import path/to/backup/dir.

Important! Importing a backup will completely blow away the current instance: it'll drop the database, delete the installed apps, and delete all raw data, replacing each with that from the backup.

The only constraints are that:

This path needs to be available from confinement, so put it in /var/snap/nextcloud/common or /var/snap/nextcloud/current/ somewhere.

User root needs to be the owner.

So continuing with the previous example, these two commands would need to be executed before importing:

sudo mv 20190121-153921_nextcloud-backup.tar /var/snap/nextcloud/current/

sudo chown -R root:root /var/snap/nextcloud/current/20190121-153921/

Selective backup

Note that you can limit what is exported (and what is imported) with arguments that are documented if you run nextcloud.export -h or nextcloud.import -h.

Example

Usage:

   nextcloud.export [OPTIONS]
   Export data suitable for migrating servers. By default this
   includes the Nextcloud database, configuration, and data
   (equivalent to running nextcloud.export -abcd).

Available options:

   -h: Display this help message
   -a: Include the (non-default) apps
   -b: Include the database
   -c: Include the config
   -d: Include the data (can be quite large)

Tips & tricks

Q. Can exporting specify the data directory?

A. Not directly, but you should be able to use a symlink. For example, creating a symlink from the data directory to /var/snap/nextcloud/common/nextcloud/data

Q. Can I somehow export/import my HTTPS certs?

A. Yes, everything related to them is stored in the /var/snap/nextcloud/current/certs directory, so copying it and preserving its permissions and owner works.

Caveats

The export/import tools are mostly written from the perspective of wanting to migrate your current install to another instance of the snap. Keep that in mind:

It won't be particularly helpful in migrating to the snap from a non-snap install

Likewise, it won't be particularly helpful in migrating away from the snap

It creates a copy of your config, trusted domains and all. If you're migrating to a new domain name, keep this in mind-- you'll need to update the trusted domains yourself.

SSL certificates

linux1 server cert locations:

ls /etc/ssl/certs/

nextcloud server cert locations, most recent and actual locations

sudo ls -l /var/snap/nextcloud/current/certs/certbot/config/live/msgsb.com
lrwxrwxrwx 1 root root  34 Apr  6 08:50 cert.pem -> ../../archive/msgsb.com/cert17.pem
lrwxrwxrwx 1 root root  35 Apr  6 08:50 chain.pem -> ../../archive/msgsb.com/chain17.pem
lrwxrwxrwx 1 root root  39 Apr  6 08:50 fullchain.pem -> ../../archive/msgsb.com/fullchain17.pem
lrwxrwxrwx 1 root root  37 Apr  6 08:50 privkey.pem -> ../../archive/msgsb.com/privkey17.pem
-rw-r--r-- 1 root root 692 Mar 24  2022 README

sudo ls -lt /var/snap/nextcloud/current/certs/certbot/config/archive/msgsb.com/ | head
-rw-r--r-- 1 root root 3968 Apr  6 08:50 fullchain17.pem
-rw-r--r-- 1 root root 2167 Apr  6 08:50 cert17.pem
-rw-r--r-- 1 root root 1801 Apr  6 08:50 chain17.pem
-rw------- 1 root root 3272 Apr  6 08:50 privkey17.pem
-rw-r--r-- 1 root root 3903 Jan 10 08:08 fullchain16.pem
-rw-r--r-- 1 root root 2102 Jan 10 08:08 cert16.pem
-rw-r--r-- 1 root root 1801 Jan 10 08:08 chain16.pem
-rw------- 1 root root 3272 Jan 10 08:08 privkey16.pem
-rw-r--r-- 1 root root 3903 Oct 19 08:40 fullchain15.pem

Directions from the web:

To mirror a web certificate across two Linux servers, you'll need to copy the certificate files (certificate and private key) and potentially a CA bundle to the second server, ensuring proper permissions and configuration.

Here's a more detailed breakdown:

1. Identify Certificate and Key Locations: Locate the certificate file (e.g., *.crt) and the private key file (e.g., *.key): on the server where the certificate is currently installed. Common locations include /etc/ssl/certs/, /etc/letsencrypt/live/, or a path configured by your web server (e.g., Apache, Nginx). If you have a CA bundle, locate that as well: (e.g., ca-bundle.crt or similar).

2. Copy the Files: Use a secure method to copy the files: (e.g., scp, rsync) from the source server to the target server. Example using scp: scp -r /path/to/certificate /path/to/private_key /path/to/ca_bundle_if_exists user@target_server:/path/to/destination/. Ensure the files are copied to a location accessible by your web server: on the target server.

3. Configure Permissions: Set appropriate permissions on the copied files and directories . The web server user should have read access to the certificate and CA bundle (if applicable). The private key should have restricted access, ideally only readable by the web server user. Example command to change ownership: sudo chown web_server_user:web_server_group /path/to/certificate /path/to/private_key /path/to/ca_bundle_if_exists.

4. Update Web Server Configuration: Modify your web server configuration (e.g., Apache, Nginx) to point to the new certificate and key locations: on the target server. Restart the web server: for the changes to take effect.

5. Optional: Concatenate Certificates (if needed): If you have multiple certificate files (e.g., the main certificate and an intermediate certificate), you might need to concatenate them into a single file (e.g., ssl-bundle.crt).

Use a command like: cat /path/to/your_certificate.crt /path/to/intermediate_certificate.crt > /path/to/ssl-bundle.crt.

Example (using Nginx):

1. Locate files: Assume your certificate is at /etc/nginx/ssl/your_domain.crt, and your private key is at /etc/nginx/ssl/your_domain.key.

2. Copy files: scp -r /etc/nginx/ssl/your_domain.crt /etc/nginx/ssl/your_domain.key user@target_server:/etc/nginx/ssl/.

3. Configure Nginx: In your Nginx configuration file (e.g., /etc/nginx/sites-available/your_domain), update the ssl_certificate and ssl_certificate_key directives to point to the new locations on the target server.

Code

ssl_certificate /etc/nginx/ssl/your_domain.crt;
ssl_certificate_key /etc/nginx/ssl/your_domain.key;

Restart Nginx: sudo systemctl restart nginx.

Main_Page Main