Microcamtest

checking the microphone and webcam

How to remotely access the Desktop of your Raspberry Pi over the internet

If the Raspberry Pi does not support WiFi

  • As a prerequisite, ensure that Raspberry Pi has SSH enabled.
  • Connect the Ethernet cable from Raspberry Pi’s ethernet slot to the Ethernet slot of your network router.
Connect RPi to the router via Ethernet Cable
  • Connect your laptop to the other ethernet slot of the router.
  • Connect Raspberry Pi to the monitor and hook up keyboard and mouse with the Pi.
  • Power up Raspberry Pi. The Graphical interface gets launched.
  • Open terminal from Raspberry Pi and type in:

This will give the IP address of Raspberry Pi for the local area network. Note that this address will be different from the last article, where you have connected the Pi and laptop via Ethernet without a network router.

Video

Configuring DDClient

During the installation,  it will probably have already asked you some questions and will have prepared a useful config file. Now you have to open this file and adjust the needed parameters:

Shell

12345678910111213141516171819 sudo vi / etc / ddclient .conf # Configuration file for ddclient generated by debconf # # /etc/ddclient.conf ssl = yes protocol = changeip # How to get your external IP use = web , web = ip .changeip .com # Update config server = nic .ChangeIP .com / nic / update login = your @ email .com password = ‘XXX’ # Domain to update eltiempo .domoticproject .com

It is important to use always SSL  to avoid sending your login name and password over the Internet unencrypted. Protocol can be set to ChangeIP, or any of the previoulsy mentioned sites in the following link. If your DDNS service provider does not appear in this list, it is probably better to use another software to update your dynamic IP. Otherwise, you will have to invest some time to adapt ddclient to your provider. The current external IP can be obtained using the web service hosted in ip.changeip.com. Update you login information, password and host to update and save the file.

Now you should be able to launch the ddclient service by by executing:

Shell

1 usr / sbin / ddclient – daemon 300 – syslog

You can place it in your startup scripts so that in the future you will only need to write:

Shell

1 sudo service ddclient start

Now you should be able to check if it is correctly running by lauching

Shell

1234567 sudo service ddclient status ●ddclient .service – LSB : Update dynamic domain name service entries Loaded : loaded ( / etc / init .d / ddclient ) Active : active ( running ) since vie 2017 – 11 – 24 22 : 27 : 59 CET ; 1 months 1 days ago CGroup : / system .slice / ddclient .service └─918 ddclient – sleeping for 190 seconds

Network File System (NFS)

Edit this on GitHub

Network File System (NFS) allows you to share a directory located on one networked computer with other computers or devices on the same network. The computer where the directory is located is called the server, and computers or devices connecting to that server are called clients. Clients usually mount the shared directory to make it a part of their own directory structure. The shared directory is an example of a shared resource or network share.

For smaller networks, an NFS is perfect for creating a simple NAS (Network-attached storage) in a Linux/Unix environment.

An NFS is perhaps best suited to more permanent network-mounted directories, such as /home directories or regularly-accessed shared resources. If you want a network share that guest users can easily connect to, Samba is better suited to the task. This is because tools to temporarily mount and detach from Samba shares are more readily available across old and proprietary operating systems.

Before deploying an NFS, you should be familiar with:

  • Linux file and directory permissions

  • mounting and unmounting filesystems

Setting up a Basic NFS Server

Install the packages required using the command below:

For easier maintenance, we will isolate all NFS exports in single directory, into which the real directories will be mounted with the --bind option.

Suppose we want to export our users’ home directories, which are in /home/users. First we create the export filesystem:

Note that /export and /export/users will need 777 permissions, as we will be accessing the NFS share from the client without LDAP/NIS authentication. This will not apply if using authentication (see below). Now mount the real users directory with:

To save us from retyping this after every reboot, we add the following line to /etc/fstab:

There are three configuration files that relate to an NFS server:

  1. /etc/default/nfs-kernel-server

  2. /etc/default/nfs-common

  3. /etc/exports

The only important option in /etc/default/nfs-kernel-server for now is NEED_SVCGSSD. It is set to "no" by default, which is fine, because we are not activating NFSv4 security this time.

In order for the ID names to be automatically mapped, the file /etc/idmapd.conf must exist on both the client and the server with the same contents and with the correct domain names. Furthermore, this file should have the following lines in the Mapping section:

However, note that the client may have different requirements for the Nobody-User and Nobody-Group. For example, on RedHat variants, it is nfsnobody for both. If you’re not sure, check via the following commands to see if nobody and nogroup are there:

This way, server and client do not need the users to share same UID/GUID. For those who use LDAP-based authentication, add the following lines to the idmapd.conf of your clients:

This will cause idmapd to know to look at nsswitch.conf to determine where it should look for credential information. If you have LDAP authentication already working, nsswitch shouldn’t require further explanation.

To export our directories to a local network 192.168.1.0/24, we add the following two lines to /etc/exports:

Portmap lockdown (optional) The files on your NFS are open to anyone on the network. As a security measure, you can restrict access to specified clients. Add the following line to /etc/ny: rpcbind mountd nfsd statd lockd rquotad : ALL By blocking all clients first, only clients in /etc/hosts.allow (added below) will be allowed to access the server. Now add the following line to /etc/hosts.allow: rpcbind mountd nfsd statd lockd rquotad : <list of IPv4s> where <list of IPv4s> is a list of the IP addresses of the server and all clients. (These have to be IP addresses because of a limitation in rpcbind, which doesn’t like hostnames.) Note that if you have NIS set up, you can just add these to the same line. Please ensure that the list of authorised IP addresses includes the localhost address (127.0.0.1), as the startup scripts in recent versions of Ubuntu use the rpcinfo command to discover NFSv3 support, and this will be disabled if localhost is unable to connect. Finally, to make your changes take effect, restart the service: sudo systemctl restart nfs-kernel-server

Configuring an NFS Client

Now that your server is running, you need to set up any clients to be able to access it. To start, install the required packages:

On the client, we can mount the complete export tree with one command:

You can also specify the NFS server hostname instead of its IP address, but in this case you need to ensure that the hostname can be resolved to an IP on the client side. A robust way of ensuring that this will always resolve is to use the /etc/hosts file.

Note that <nfs-server-IP>:/export is not necessary in NFSv4, as it was in NFSv3. The root export :/ defaults to export with fsid=0.

We can also mount an exported subtree with:

To ensure this is mounted on every reboot, add the following line to /etc/fstab:

If, after mounting, the entry in /proc/mounts appears as <nfs-server-IP>:// (with two slashes), then you might need to specify two slashes in /etc/fstab, or else umount might complain that it cannot find the mount.

Portmap lockdown (optional) Add the following line to /etc/ny: rpcbind : ALL By blocking all clients first, only clients in /etc/hosts.allow (added below) will be allowed to access the server. Now add the following line to /etc/hosts.allow: rpcbind : <NFS server IP address> where <NFS server IP address> is the IP address of the server.

A More Complex NFS Server

NFS user permissions are based on user ID (UID). UIDs of any users on the client must match those on the server in order for the users to have access. The typical ways of doing this are:

  • Manual password file synchronisation

  • Use of LDAP

  • Use of DNS

  • Use of NIS

Note that you have to be careful on systems where the main user has root access: that user can change UIDs on the system to allow themselves access to anyone’s files. This page assumes that the administrative team is the only group with root access and that they are all trusted. Anything else represents a more advanced configuration, and will not be addressed here.

Group permissions

A user’s file access is determined by their membership of groups on the client, not on the server. However, there is an important limitation: a maximum of 16 groups are passed from the client to the server, and if a user is member of more than 16 groups on the client, some files or directories might be unexpectedly inaccessible.

DNS (optional, only if using DNS)

Add any client name and IP addresses to /etc/hosts. (The IP address of the server should already be there.) This ensures that NFS will still work even if DNS goes down. Alternatively you can rely on DNS if you want – it’s up to you.

NIS (optional, only if using NIS)

This applies to clients using NIS. Otherwise you can’t use netgroups, and should specify individual IPs or hostnames in /etc/exports. Read the BUGS section in man netgroup for more information.

First, edit /etc/netgroup and add a line to classify your clients (this step is not necessary, but is for convenience):

where myclients is the netgroup name.

Next run this command to rebuild the NIS database:

The filename yp refers to Yellow Pages, the former name of NIS.

Portmap lockdown (optional)

Add the following line to /etc/ny:

By blocking all clients first, only clients in /etc/hosts.allow (added below) will be allowed to access the server.

Consider adding the following line to /etc/hosts.allow:

where <list of IPs> is a list of the IP addresses of the server and all clients. These have to be IP addresses because of a limitation in rpcbind. Note that if you have NIS set up, you can just add these to the same line.

Package installation and configuration

Install the necessary packages:

Edit /etc/exports and add the shares:

The example above shares /home and /usr/local to all clients in the myclients netgroup.

The example above shares /home and /usr/local to two clients with static IP addresses. If you want instead to allow access to all clients in the private network falling within a designated IP address range, consider the following:

Here, rw makes the share read/write, and sync requires the server to only reply to requests once any changes have been flushed to disk. This is the safest option; async is faster, but dangerous. It is strongly recommended that you read man exports if you are considering other options.

After setting up /etc/exports, export the shares:

You’ll want to run this command whenever /etc/exports is modified.

Restart services

By default, rpcbind only binds to the loopback interface. To enable access to rpcbind from remote machines, you need to change /etc/conf.d/rpcbind to get rid of either -l or -i 127.0.0.1.

If any changes are made, rpcbind and NFS will need to be restarted:

Security items to consider Aside from the UID issues discussed above, it should be noted that an attacker could potentially masquerade as a machine that is allowed to map the share, which allows them to create arbitrary UIDs to access your files. One potential solution to this is IPSec. You can set up all your domain members to talk to each other only over IPSec, which will effectively authenticate that your client is who it says it is. IPSec works by encrypting traffic to the server with the server’s public key, and the server sends back all replies encrypted with the client’s public key. The traffic is decrypted with the respective private keys. If the client doesn’t have the keys that it is supposed to have, it can’t send or receive data. An alternative to IPSec is physically separate networks. This requires a separate network switch and separate Ethernet cards, and physical security of that network.

Troubleshooting Mounting an NFS share inside an encrypted home directory will only work after you are successfully logged in and your home is decrypted. This means that using /etc/fstab to mount NFS shares on boot will not work, because your home has not been decrypted at the time of mounting. There is a simple way around this using symbolic links: Create an alternative directory to mount the NFS shares in: sudo mkdir /nfs sudo mkdir /nfs/music Edit /etc/fstab to mount the NFS share into that directory instead: nfsServer:music /nfs/music nfs auto 0 0 Create a symbolic link inside your home, pointing to the actual mount location. For example, and in this case deleting the Music directory already existing there first: rmdir /home/user/Music ln -s /nfs/music/ /home/user/Music

Network boot your Raspberry Pi

Edit this on GitHub

You can set up a DHCP/TFTP server which will allow you to boot a Raspberry Pi 3 or 4 from the network.

The instructions assume that you have an existing home network, and that you want to use a Raspberry Pi for the server. You will also need an additional Raspberry Pi 3 or 4 as a client to be booted. Only one SD Card is needed because the client will be booted from the server after the initial client configuration.

Note

Due to the huge range of networking devices and routers available, we can’t guarantee that network booting will work with any device. We have had reports that, if you cannot get network booting to work, disabling STP frames on your network may help.

Client Configuration

Raspberry Pi 3 Model B

Note
This section only applies to the Raspberry Pi 3 Model B, as network boot is enabled on the Raspberry Pi 3 Model B+ at the factory.

Before the Raspberry Pi 3 Model B will network boot it needs to be booted from an SD Card with a config option to enable USB boot mode. This will set a bit in the OTP (One Time Programmable) memory in the Raspberry Pi SoC that enables network booting. Once this is done, the Raspberry Pi 3B will attempt to boot from USB, and from the network, if it cannot boot from the SD card.

Install Raspberry Pi OS Lite, or Raspberry Pi OS with desktop, on the SD card in the usual fashion. Next, enable USB boot mode with the following command:

This adds program_usb_boot_mode=1 to the end of /boot/config.txt. Reboot the Raspberry Pi with sudo reboot. Once the client Raspberry Pi has rebooted, check that the OTP has been programmed with:

Ensure the output 0x3020000a is correct.

The client configuration is almost done. The final thing to do is to remove the program_usb_boot_mode line from config.txt. You can do this with sudo nano /boot/config.txt, for example. Finally, shut the client Raspberry Pi down with sudo poweroff.

Raspberry Pi 4 Model B Network boot can be enabled on the Raspberry Pi 4 using the raspi-config tool. First, run raspi-config as follows: sudo raspi-config Within raspi-config, choose Advanced Options, then Boot Order, then Network Boot. You must then reboot the device for the change to the boot order to be programmed into the bootloader EEPROM. Once the Raspberry Pi has rebooted, check that the boot order is now 0xf21: vcgencmd bootloader_config For further details of configuring the Raspberry Pi 4 bootloader, see Raspberry Pi 4 Bootloader Configuration.

Ethernet MAC address

Before configuring network boot, make a note of the serial number and mac address so that the board can be identified by the TFTP/DHCP server.

On Raspberry Pi 4 the MAC address is programmed at manufacture and there is no link between the MAC address and serial number. Both the MAC address and serial numbers are displayed on the bootloader HDMI diagnostics screen.

To find the Ethernet MAC address:

To find the serial number:

grep Serial /proc/cpuinfo | cut -d ‘ ‘ -f 2 | cut -c 8-16

Server Configuration

Plug the SD card into the server Raspberry Pi, and then boot the server. The client Raspberry Pi will need a root file system to boot from: we will use a copy of the server’s root filesystem and place it in /nfs/client1:

Regenerate SSH host keys on the client filesystem by chrooting into it:

Find the settings of your local network. You need to find the address of your router (or gateway), which can be done with:

Then run:

which should give an output like:

The first address is the IP address of your server Raspberry Pi on the network, and the part after the slash is the network size. It is highly likely that yours will be a /24. Also note the brd (broadcast) address of the network. Note down the output of the previous command, which will contain the IP address of the Raspberry Pi and the broadcast address of the network.

Finally, note down the address of your DNS server, which is the same address as your gateway. You can find this with:

Configure a static network address on your server Raspberry Pi via the systemd networking, which works as the network handler and DHCP server.

To do that, you’ll need to create a dev and a work like so:

Add the following lines:

Then create a network file:

Add the following contents:

At this point, you will not have working DNS, so you will need to add the server you noted down before to systemd/resolved.conf. In this example, the gateway address is 10.42.0.1.

Uncomment the DNS line and add the DNS IP address there. Additionally, if you have a fallback DNS server, add it there as well.

Enable systemd-networkd and then reboot for the changes to take effect:

Now start tcpdump so you can search for DHCP packets from the client Raspberry Pi:

Connect the client Raspberry Pi to your network and power it on. Check that the LEDs illuminate on the client after around 10 seconds, then you should get a packet from the client “DHCP/BOOTP, Request from …​”

Now you need to modify the dnsmasq configuration to enable DHCP to reply to the device. Press CTRL + C to exit the tcpdump program, then type the following:

Then replace the contents of dnsmasq.conf with:

Where the first address of the dhcp-range line is, use the broadcast address you noted down earlier.

Now create a /tftpboot directory:

Now monitor the dnsmasq log:

You should see something like this:

Next, you will need to copy the contents of the boot folder into the /tftpboot directory.

First, press CTRL + C to exit the monitoring state. Then type the following:

Since the tftp location has changed, restart dnsmasq:

Set up NFS root This should now allow your Raspberry Pi client to attempt to boot through until it tries to load a root file system (which it doesn’t have). At this point, export the /nfs/client1 file system created earlier, and the TFTP boot folder. sudo apt install nfs-kernel-server echo “/nfs/client1 *(rw,sync,no_subtree_check,no_root_squash)” | sudo tee -a /etc/exports echo “/tftpboot *(rw,sync,no_subtree_check,no_root_squash)” | sudo tee -a /etc/exports Restart RPC-Bind and the NFS server in order to have them detect the new files. sudo systemctl enable rpcbind sudo systemctl restart rpcbind sudo systemctl enable nfs-kernel-server sudo systemctl restart nfs-kernel-server Edit /tftpboot/cmdline.txt and from root= onwards, and replace it with: root=/dev/nfs nfsroot=10.42.0.211:/nfs/client1,vers=4.1,proto=tcp rw ip=dhcp rootwait You should substitute the IP address here with the IP address you have noted down. Also remove any part of the command line starting with init=. Finally, edit /nfs/client1/etc/fstab and remove the /dev/mmcblk0p1 and p2 lines (only proc should be left). Then, add the boot partition back in: echo “10.42.0.211:/tftpboot /boot nfs defaults,vers=4.1,proto=tcp 0 0” | sudo tee -a /nfs/client1/etc/fstab Good luck! If it doesn’t boot on the first attempt, keep trying. It can take a minute or so for the Raspberry Pi to boot, so be patient.

Using pxetools We have created a Python script that is used internally to quickly set up Raspberry Pis that will network boot. The script takes a serial number, which you can find in cat /proc/cpuinfo, an owner name and the name of the Raspberry Pi. It then creates a root filesystem for that Raspberry Pi from a Raspberry Pi OS image. There is also a –list option which will print out the IP address of the Raspberry Pi, and a –remove option. Note The following instructions describe how to set up the environment required by the script starting from a fresh Raspberry Pi OS lite image. It might be a good idea to mount a hard disk or flash drive on /nfs so that your SD card isn’t providing filesystems to multiple Raspberry Pis. This is left as an exercise for the reader. sudo apt update sudo apt full-upgrade -y sudo reboot wget https://datasheets.raspberrypi.com/soft/prepare_pxetools.sh bash prepare_pxetools When prompted about saving iptables rules, say no. The prepare_pxetools script should prepare everything you need to use pxetools. We found that we needed to restart the nfs server after using pxetools for the first time. Do this with: sudo systemctl restart nfs-kernel-server Then plug in your Raspberry Pi and it should boot!

Recent Posts

Tags