Please focus on one thing.
shiny-mirrors is an alternative to pacman-mirrors
'K
I had started to read that article, but it seemed to be about Manjaro Apps, so I discarded it… Thanks I’ll read it properly.
@ linux-aarhus thanks
I’ll let you guys know as soon as I get this set up, could take a while though.
… not really a repo mirror here
but may be easier and more effective
With my Manjaro virtual machines I do that kind of thing
which essentially is:
download only once and use for all
by having a separate disk, which I mount to /var/cache/pacman/pkg
on each machine
All the machines are then using the same package cache.
This same thing could be achieved using a server and (NFS or sshfs) mounting a directory on it to
/var/cache/pacman/pkg on each machine.
This way, not the whole repo needs to be cloned - but just the packages that are actually needed.
Just another idea …
But…but…
as @ mithrial says, that’s probably pacserve. I’ll go with setting up a Mirror on my File server. I have plenty of space, and I already have Apache running on it.
It will take a while 'cos of finding the time to concentrate on actually doing the job. It’s coming into Fire Season over here, so were pretty busy making sure only our Bush burns, and not the house.
My scenario was
VM’s, I run them one at a time, not simultaneously.
My only requirement is not to download all the updates multiple times for each of them but re-use them once they are present.
No need for the full repo and sharing the cache via pacserve would require more than one to be running at a time which is never the case.
Just a primitive re-use of the pacman cache.
You describe a scenario that is unique to you, and probably be too complicated for OP.
If your server is already running apache, then all you have to do is mirror one of the mirrors to any subdirectory of apache, and point your clients to this server.
… maybe
It’s a network mount - plenty of documentation on that.
It was just another way to do it.
And it avoids mirroring the whole mirror when only a few packages are actually needed.
That is how I understood how pacserve works.
But I’m not sure about that.
changed because only the pacman cache is shared
… would not have worked for me anyway
If you don’t have it already - setup a web server on your ubuntu box and create a manjaro subfolder.
Then setup a script and a systemd timer to sync from the repo.
Create a script folder
sudo mkdir /etc/systemd/scripts
Create a file /etc/systemd/scripts/rsync-manjaro.sh and make it executable
sudo touch /etc/systemd/scripts/rsync-manjaro.sh
sudo chmod +x /etc/systemd/scripts/rsync-manjaro.sh
Edit the file as root and paste below content
#!/bin/sh
# This is a simple mirroring script. To save bandwidth it first checks a
# timestamp via HTTP and only runs rsync when the timestamp differs from the
# local copy. As of 2016, a single rsync run without changes transfers roughly
# 6MiB of data which adds up to roughly 250GiB of traffic per month when rsync
# is run every minute. Performing a simple check via HTTP first can thus save a
# lot of traffic.
# EDIT to match your system
TARGET=/var/www/manjaro
# possible rsync mirrors
# https://wiki.manjaro.org/index.php/Manjaro_Mirrors
# https://forum.manjaro.org/t/root-tip-how-to-create-manjaro-mirror-server/21264#syncing-the-repo-from-another-mirror-17
#SOURCE="rsync://ftp.halifax.rwth-aachen.de/manjaro/"
SOURCE="rsync://mirror.easyname.at/manjaro/"
TMP="/var/tmp/manjaro"
LOCK="/tmp/rsync-manjaro.lock"
# NOTE: You'll probably want to change this or remove the --bwlimit setting in
# the rsync call below
BWLIMIT=100000
[ ! -d "${TARGET}" ] && mkdir -p "${TARGET}"
[ ! -d "${TMP}" ] && mkdir -p "${TMP}"
exec 9>"${LOCK}"
flock -n 9 || exit
## if we are called without a tty (cronjob) only run when there are changes
#if ! tty -s && diff -b <(curl -s "${STATE}") "${TARGET}/state" >/dev/null; then
# exit 0
#fi
if ! stty &>/dev/null; then
QUIET="-q"
fi
# excluded fh 2016-11-01
rsync -rtlvH --safe-links \
--bwlimit=${BWLIMIT} \
--delete-after --progress \
-h ${QUIET} --timeout=300 --contimeout=120 -p \
--delay-updates --no-motd \
--temp-dir="${TMP}" \
--exclude='/arm-stable' \
--exclude='/arm-testing' \
--exclude='/arm-unstable' \
--exclude='/pool/overlay-arm' \
--exclude='/pool/sync-arm' \
${SOURCE} \
"${TARGET}"
rm -f ${LOCK}
EOF
Run the script as root to do the initial sync - I don’t know how much the arm-repos are worth but I think a lot - and there’s no benefit from excluding branches as branch files - except database files - are symlinks to actual files in the pool.
If you have no need for the arm branches you can get down to around 90G only for x86_64 - I have modified the sync script to exclude arm.
When you have synced the repos - create a service and a timer
sudo touch /etc/systemd/system/rsync-manjaro.service
sudo touch /etc/systemd/system/rsync-manjaro.timer
Edit the service file and paste below
[Unit]
Description=Sync manjaro repo
[Service]
Type=oneshot
ExecStart=/etc/systemd/scripts/rsync-manjaro.sh
[Install]
WantedBy=multi-user.target
Edit the timer file and paste below
[Unit]
Description=Sync Manjaro mirror on a daily base
[Timer]
Persistent=true
OnCalendar=daily
[Install]
WantedBy=timers.target
Then enable the timer
sudo systemctl enable --now rsync-manjaro.timer
Thanks I’ve complimented this. I’ll guess I’ll know shortly how well it works.
I do have one minor problem.
I am now unable to sync the AUR database.
I have a couple of AUR packages installed on two of the computers. Most importantly is Mullvad-VPN.
AUR has nothing to do with the package repositories.
@mithrial That’s correct.
and yet… on multiple computers it no longer synchronises.
To be specific, when one synchronises databases using the GUI the message returned is ‘Failed to synchronise AUR database’
I am sorry to butt in like this when it was already solved but to me this is just too unnecessary and complicated with no good pros only cons,
I think it doesn’t make sense to make custom pool for just one local mirror,
I would just disable the timer and set in /etc/pacman.d/mirrorlist the local IP of the mirror
like so: Server = <protocol>://<local_IP>/<branch>/$repo/$arch
And it’s done
There is no need to keep using any kind of mirror helper(pacman-mirrors or shiny-mirrors), in such case it’s useless when you are going to use only one mirror.
In Pamac preferences - uncheck the option to check for AUR updates.
In any case it has has nothing to do with your mirror pool but more the recurring misbehaving of the CDN aur.manjaor.org.
That is correct - but any rerun of pacman-mirrors will rewrite the mirrorlist.
If one is managing a pool of systems with different users - e.g. family on different locations - then it is necessary to take precautions and ensure the updates are fetched in a controlled environment - then it is not enough to just set the mirror in the mirrorlist.
@tracyanne
If any interest - I have a customized pacman-mirrors PKGBUILD which patches the sources to facilitate precisely such scenario.
The undocumented feature mentioned earlier has been created to support a use case with a large amount of Manjaro systems maintained by an IT department - to ensure a homogeneus pool of systems.
Given I do have some AUR packages installed, most importantly Mullvad-VPN, what affect will that have when Mullvad releases an update?
Even pamac can do it - it does not indicate it is a good idea to automate rebuild of AUR packages.
Let’s me emphasize - changing your mirror pool to a locally maintainedl mirror does not in any way affect how Pamac rebuilds AUR packages.
IMO opinion AUR packages is best maintained manually. Given the somewhat unstable mirror of the AUR database maintained by Manjaro - the manual check makes even more sense.
You can use yay to check if updates are available for your installed custom packages.
yay -Qua
You could create a simple script using inotify to show a message if theres updates to your custom packages - then use systemd to run the script as your user.
OK thanks. I forgot about yay.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.