Update Accelerator, today

I have read the latest iPFire documentation regarding Update Accelerator, which also refers to a PDF that summarizes the threads from 2015 to 2019.
In those years there was an official version and a new version which also differed in the number of package types detected and placed in the cache.
What is the situation today?
I imagine there is only the official version.

Today there is the official, ‘old’, version, only.
I started with my ideas some years ago. Because of not much responses then, the project stopped.
I know there is some interest about this theme. Therefore I’ll start a new attempt for a realization.
The main changes will be:

  • definition of the packages ( URLs ) by regular expressions;
    one per ‘vendor’
    holding a history to speed up the search process

  • migrating the data to a real data base
    this is a second step for speed up

The first topic can be realized and tested soon, I hope. Most changes of my first attempt were in the data base field, which will be separated now.

3 Likes

Thanks for your reply.
If there is room for suggestions:

  1. a simplification to create new “packages” to caching
  2. the ability to use a second disk instead of IPFire’s default one.

Im not sure if it’s a good idea to spend time in this project. The proxy (redirectors) support only http but the most traffic is now https so it cannot cached at all.

This can already done by move the /var/updatecache folder to the new disc and create a symlink that point to the new location.

1 Like

@whitetiger : The simplification will be feature of this rewrite.
Generally, there will be definition files <vendor> with contents

t, <type>
p, <URL>
n, <URL>

with <type> is unique or mirror
p lines are URLs which match
n lines are URLs which shall not match

@arne_f : I don’t think, that https URLs are not catched. If the proxy is non-transparent all requests are passed to the redirector. This is my experience.
You are right. For HTTPS a CONNECT request to the host is generated only. So a handling of the download URLs isn’t possible.

Below I show some statistics from several IPFire
(transparent proxy)

Installed circa 2021.05

Installed circa 2021.05

Installed circa 2020.07

Installed circa 2021.11

Edit:
If the above statistics are not helpful, tell me, then I will delete my post.

Hi all,

others configurations (installed in January 2020 - core update 160) :

Installed in august 2019 - core update 162) :

So what? I do not understand.
U.A. it does not work anymore?

@tphz , @steph78630
Forgive me, but I can’t understand what you mean by these statistics?
I see that it is also working with Transparent

1 Like

I think this basically means that if your updates come from an http website then Update Accelerator will still be able to help you but if the updates come from an https website then the web proxy (squid) does not decrypt the contents so it purely passes all the bits from the server to the client requesting the data. Therefore it has no information to know what bits should be cached or not. The start of the wiki page on General info on squid covers this.

https://wiki.ipfire.org/configuration/network/proxy/general

This means that only http websites are being used as transparaent can not work with https as the content is not decrypted in IPFire but at the client.

1 Like

Hi @whitetiger,

absolutely, my IPFires are running in transparent mode!

I shared these statistics only for example (update accelerator can also manage other editors like Apple, Linux, Symantec, etc. with a higher cache efficiency index)

Note [Edit] : On some low speed Internet links [xDSL] or shared with many machines (Windows !), activating the update accelerator saved my life and economize update times - Many thanks for this feature !

2 Likes