The logs show that there is/was a problem with the download
... pakfire: DOWNLOAD INFO: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-184.ipfire has size of bytes
There is a small issue in the error handling of pakfire.
This isnāt āniceā, but it is assured that complete and verified downloads are installed.
In case of such errors just try again. Sometimes mirrors have hick-ups.
Itās been on strike for a week, and now itās suddenly working on the other Internet connection on my desk.
Itās a bit strange.
I donāt understand it.
The update was started several times.
It was also restarted several times.
The internet connection was also OK.
The IP from the provider was reassigned daily.
Could IP blocking on the downlod server be the cause?
After the first pakfire update, a list of mirrors was downloaded. The question was whether it was always mirror.clarkson.edu or sometimes another of the 21 mirrors.
I canāt tell now because itās already back at the site. But I was told that it had the problem once with an older update.
Do you have enough free disk space?
More than enough 360Gb
Did āpakfire update --forceā on the command line or via ssh change anything?
Update was done via the web interface.
Iāll wait until the next update to see if everything works.
Can you access the message log remotely (via VPN and SSH)?
if yes, then enter this command and post the results:
grep pakfire /var/log/messages
I ran the above command on my IPFire and the results are about 200 lines. Also I did not see any āprivateā info in the results so it is OK to post.
Just more information, especially concerning the error, can be sampled with zgrep pakfire /var/log/messages*|grep -A 1 Host
This searches all messages files and shows the mirror URL and the filesize ( which shouldnāt be empty! ).
No the computer is back at its location (approx 270km)and there is no way to access it remotely.
I will make a note of the information.
According to information from the user, this has happened before.
If the error occurs again, I will report further here.
I am confused. Why do you want SSH agent Forwarding or TCP forwarding? SSH Agent forwarding allows you to go via IPFire to another server using keys without doing a second login. TCP forwarding just allows you to to forward a packet from a port in IPF to a port on another server.
Surely what you want for security is to disallow password authentication and allow Public Key authentication, if you are going to use direct SSH access. At this point you can then use SSH TCP Forwarding locally (not on IPF) to forward port 444 from localhost to IPF:444.
Alternatively, as Jon said, use a VPN and then you can access SSH directly (and the UI).
The IPFire has no connection to the Internet, it only separates two networks securely from each other.
The machine control is accessed via VPN via the IPFire, everything else remains off.
Some people in the office are just too playful and have to play around with everything they can get their hands on.
Logging on to the IPFire, whether console or web interface, is only possible if a USB dongel is plugged in.
Without this, even root cannot log in.
