Issue with the MetaRepository repo

MrDini · July 2019

Hi again,

I got an NSA310 to make it "smarter" for a few days.

It already had MetaRepository installed however with the old nas-central urls. Therefore I felt like I should update.

Firstly I modified the config like this:

# Mijzelf's repository
https://nas-central.mrdini.me/Users/Mijzelf/zypkg-repo/ Mijzelf

That didn't work out... Then I took a deeper look on the metarepo logs. Here is the full one: [link]

So it tries to use the fw built in curl located at /usr/bin/curl. That's not the best for me I thought because it uses the fw built-in libcrypto and libssl:

root@NSA310:~# readelf -a /usr/bin/curl | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libssl.so.0.9.8]
 0x00000001 (NEEDED)                     Shared library: [libcrypto.so.0.9.8]
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libz.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

So it fails with the CloudFlare SNI SSL what I have on my repo mirror:

root@NSA310:~# /usr/bin/curl https://nas-central.mrdini.me/Users/Mijzelf/zypkg-repo/ZYPKG_INFO.tgz --insecure > /dev/null

curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

I have FFp installed with the latest curl from the good old barmalej2 repository and that one works fine.

However because of the default ordering in MetaRepo's pkgcgi.cgi, the fw built-in one will be used always:

for path in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /usr/local/bin/ /usr/local/sbin/ /opt/bin/ /opt/sbin/ /ffp/bin/ /ffp/sbin/

I would prefer to keep https on my mirror, so making it http only isn't really an option.

Then I decided to go with the repository provided by @Mijzelf which seemed HTTP only and therefore perfect to me. That seems to be failing also and here is the log: [link]

If I do a manual curl I can get the files fine.

So what should I do to have the Mijzelf repo working?

#NAS_Jul_2019

Mijzelf · July 2019

Fetch http://zyxel.diskstation.eu/Users/Mijzelf/zypkg-repo/ZYPKGS

On that mirror that should be http://zyxel.diskstation.eu/Users/Mijzelf/zypkg-repo/fw4 or -fw5, depending on your box. On nas-central that was / or /NAS500/, which was a bit ad-hoc. So now I had the chance I changed it.

And no, I'm not going to make the search path configurable using the webinterface, as that still doesn't solve the initial install problem.

For existing installations there are 2 work arounds, monkey patching, and using the internal repo on harddisk.

Mijzelf · July 2019

Your link to the 2nd log is the wrong one.

I tried your repository with the build-in curl on my NAS520, and it works. So your problem is fw4 only, I suppose.

I think there is no real solution for your problem. When the build in download tools fails, you won't be able to install MR, and no change in the package can solve that. The path in web_prefix has to be accessible by firmware tools.

The search for curl in those paths are on purpose. I could have called curl without specification, as an early version of MR did. But on some box with an ffp stick somehow MR used ffp wget, which was broken. Don't know how that is possible, as ffp is not in the search path for apache, and so not for MR. But I think the owner had injected it to get a newer php or something like that. Anyway, that wget was broken.

So I searched for the binary to explicitly call it, as build-in binaries are harder to break. Later I added curl support, as that also supported https links, and didn't change the search path.

But of course you can change it manually when needed.

BTW, are you aware that the latest MR on the 'other mirror' is updated to support mirrors explicitly? Some packages (like MidnightCommander on an fw5 device) needs to download some extra libraries, and it was hardcoded to nas-central. The latest MR tells the package on install where it came from, so it can adjust it's internal url's.

MrDini · July 2019

Sorry for the link, this forum engine is a bit annoying when it comes to inserting them so I managed to insert the wrong url. Will send the correct logs tomorrow.

Maybe depending on the success of the found curl binary we could force MR to check ffp's first and then if that's breaking return to the original one. Or maybe you could ship a curl binary... Or would that be overkill? Actually a simple textbox for the curl/wget pathes would be amazing to have so anyone can adjust those settings without monkey patching your code and therefore break the ability of upgrading MR without loosing the commit...

If that's too much to ask I understand! Ty

MrDini · July 2019

The other log: https://pastebin.com/7qQPRR6Z

Issue with the MetaRepository repo

Accepted Solution

All Replies

Categories

Consumer Product Help Center