— door Evert Mouw
Use case
Your personal files are on your *nix-based fileserver. Using a network filesystem, you mount the server shares on your personal computer, a Linux desktop. You want to be able to quickly find files on the server.
Actually, you also have a laptop and a few other PCs. On all those machines, you want instant search results for filename queries on the server. You only want to do indexing on your server because your other machines are often switched off and besides, indexing could be slow over the network and why should all those machines do redundant work?
Summary
Using mlocate, we run a cronjob on the server to do a regular updatedb process. We make sure that the base directory path for both server and clients is the same, using bind mounts. The updatedb database file will be stored in a location that is accessible for the clients.
The clients will copy the database file. An environment variable LOCATE_PATH will be added on the clients using their .profile configuration file, so that the additional locate database file will be used.
On the client, you can use a regular locate command, or use frondends such as catfish or other tools, e.g. feeding the results in fzf.
On the Server
fstab
If the directory paths on your server differ from the mount paths on your clients, then you have to add bind mounts in /etc/fstab.
|
1 2 3 4 |
/data/share1 /mnt/share1 none bind /data/share2 /mnt/share2 none bind /data/share3 /mnt/share2 none bind |
updatedb script
Create a shellscript, e.g. updatedb_mounts.sh, which is responsible for the creation of database files. For each path or mountpoint, initially do e.g. touch /mnt/share1/mlocate.db and make sure it has the correct file permissions. Note that the directory paths of these mountpoints should be identical to the mountpoints on the clients.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
#!/bin/sh # create a mlocate database for a specific location MOUNTS="/mnt/share1 /mnt/share2 /mnt/share3" for MOUNT in $MOUNTS do if ! [[ -f $MOUNT/mlocate.db ]] then echo "Couldn't updatedb $MOUNT, is it mounted?" exit 1 fi updatedb -l 0 -o $MOUNT/mlocate.db -U $BASEDIR done |
Store this file in e.g. /usr/local/bin and make it executable using chmod +x.
cron
Finally, we have to make sure this script is executed on a regular basis. You can do so by editing /etc/crontab, making a systemd timer, or whatever. If the shared files don’t change that often, a daily run will do:
|
1 |
ln -s /usr/local/bin/updatedb_mounts.sh /etc/cron.daily/updatedbmounts |
On the Client
If your local network mountpoint differs from the server mountpoint, then follow the same bind mount trick as being explained for the server. For now, let’s assume the mountpoints have the same path.
You can use the mlocate database files from the server directly, although I would only recommend this for a Local Area Network (LAN).
.profile
Edit your ~/.profile settings and add a LOCATE_PATH environment variable. The full filepaths to the mlocate database files should be separated by a colon (:).
|
1 |
export LOCATE_PATH="/mnt/share1/mlocate.db:/mnt/share2/mlocate.db:/mnt/share3/mlocate.db" |
Logoff, login again, and you’re set to go. Just use locate (r catfish or locate_and_select.sh (see below) or whatever tool you like to search for your files on the server.
local copy of database
Another approach for even faster search is to regularly copy the mlocate database files to a local directory and use that local copy in your LOCATE_PATH environment variable. This is easy to implement; just a cronjob and a regular file copy operation suffice. Make sure your local copy doesn’t stay behind the version stored on the server.
Locate and Select
If you only want to use locate than the catfish utility can be slow. Feeding the results of locate to fzf or rofi and using the selection to automatically open a (GUI) file manager is another approach that can work very well. You might be interested in my own script, Locate and Select.
Wees de eerste om te reageren