[SOLVED] 2.1 -> 2.1.2: Custom Repository not working

Hobby-Student

Hey guys and girls,

I have a pfSense based on an ALIX-Board with nanoBSD which was running for 200 days since the last upgrade. The only package I have installed was squid (pbi from my own repository).

Problem:

~~After the upgrade, there are no Installed Packages. However, squid is installed but not working.~~
Also, my repository is not browsable. pfSense getting no code "200". Default repository is working.
I decided to switch back to the other boot slice and restarted. Everything is working normal, ~~except the Installed Packages are gone. I can browse the Available Packages, and squid is listed for install, but it's already running and working nicely.~~
Back on 2.1 my repository is working.

Question:

~~Is there a way to rebuild the package cache?~~
Do I need to change things in my repository for 2.1.2?

Thanks in advance
Chris

EDIT:
After restoring config, Installed Packages are back normal. However, the repository question is not solved…

doktornotor

You know why your packages repository does not work any more? Well, because some genius - yet again - thought they'd break things first and think about strategy later. So, custom repos feature is now officially silently deprecated, heck… (You can still browse manually to http(s)://<pfsense>/pkg_mgr_settings.php if you type that manually to the URL bar and see if it still works if you reconfigure it that way, according to your experience, I'd say it does not.)

Sneaking similar utterly BS changes into a critical security bugfix release and not even bothering to mention that in changelog of course also absolutely rocks. And to top it off, lets cut package maintainers off the commit access.

This wannabe "open-source" project is going downhill extremely fast.

:( >:(</pfsense>

cmb

Nothing has been changed re: support of custom package repos. 2.1.2 is the same in that regard as every past release. If your custom package repo doesn't work, it's because it's broken.

Though deprecating that support since so many people show up here with package problems that later turn out to be because they're installing packages from some random person's free hosting account on a server that serves malware, is good for security reasons. Not that there won't be ways of working around it.

Re: requiring pull requests on packages, that's also for security reasons, the master git server is now on a private network and it syncs out to github where it's publicly-viewable.

doktornotor

@cmb:

Re: requiring pull requests on packages, that's also for security reasons, the master git server is now on a private network and it syncs out to github where it's publicly-viewable.

When a "security solution" kills productivity and cuts off maintainers of the repo access, making it basically impossible for them to do their work, such solution is unfit for purpose, completely retarded and should not have ever been implemented in the first place. Let alone without notifying those people first (guys you STILL do not get how incredibly rude this is and that you are having serious issues in the human relations dept.?)

Well, I certainly do NOT buy into this explanation in the first place, however there's a dedicated thread about the direction of the whole project, with astonishing silence from ESF.

Hobby-Student

@cmb:

Nothing has been changed re: support of custom package repos. 2.1.2 is the same in that regard as every past release. If your custom package repo doesn't work, it's because it's broken.

The repo is working perfectly with 2.1 and several pfSense boxes… How could it be broken?
Do I need any changes in the repo for newer releases?

doktornotor

@Hobby-Student:

Do I need any changes in the repo for newer releases?

That is a classified information…

Mama's gonna check out all your girl friends for you
Mama won't let anyone dirty get through
Mama's gonna wait up till you get in
Mama will always find out where
You've been
Mamma's gonna keep baby healthy and clean…

P.S. Secure boot coming soon. :P

Hobby-Student

@doktornotor:

That is a classified information…

I see…. It seems that you have some negative impressions :o

Anyway. The topic is serious and I would be very happy to get these classified informations ;)

doktornotor

Yeah, this topic is serious, however the "owner" of this (long ago forked community) project has chosen to behave like a moron and there's apparently nothing to change his mind. Maybe he is at least ashamed of himself and so he has kept hit trap shut for weeks and pretends to be invisible.

Other than that, you are wasting your time with creating your own packages. Instead, you should create your own project.

Hobby-Student

@doktornotor:

Other than that, you are wasting your time with creating your own packages. Instead, you should create your own project.

I think this is a bit more than people with custom repositories need… For myself it would be enough, if I could add PBI's manual in the GUI without using any repository. But that is is OT.

I will have a look at the source and try to get some more information...

Hobby-Student

Ok… This problem is just one of "please don't do this in the same main version of the product"... :o

On 2.1:
You need the repo to have a server root with 2 subdirectories and nothing else: "/pfSense" and "/packages" (both in the root of repo)


http://your-repo.domain.tld/pfSense
http://your-repo.domain.tld/packages

On 2.1.2 (don't know for 2.1.1):
You need the "/pfSense" content be the root and a subdirectory "/packages".


http://your-repo.domain.tld/
http://your-repo.domain.tld/packages

Small change, but big impact. Optionally you can use https of course…
Would be nice to see this one in the documentation.

cromero

@Hobby-Student:

On 2.1.2 (don't know for 2.1.1):
You need the "/pfSense" content be the root and a subdirectory "/packages".
http://your-repo.domain.tld/
http://your-repo.domain.tld/packages

Hi Hobby-Student

I did that but my two pfSense updated to 2.1.2 still said "Unable to communicate with X.X.X.X. Please verify DNS and…" I changed $path_to_files in xmlrpc.php and correct '../packages/' but not work. ¿Any ideas?

Hobby-Student

@cromero:

…I changed $path_to_files in xmlrpc.php and correct '../packages/' but not work. ¿Any ideas?

xmlrpc.php, line 45:


$path_to_files = './xmlrpc/';

xmlrpc.php, line 124:


$path_to_files = './packages/';

This should do the trick.

cromero

@Hobby-Student:

This should do the trick.

Yes, I did the "./packages/" change and the other no needed because always work with "./xmlrpc/" and have communication problem yet. No more changes needed in other files?

Hobby-Student

@cromero:

Yes, I did the "./packages/" change and the other no needed because always work with "./xmlrpc/" and have communication problem yet. No more changes needed in other files?

Was the repo working on 2.1?
Have you set right permissions on your webserver?
.htaccess as mentioned in the official wiki?
is test.php and xmlrpc_tester.php working? (just open in browser and see if it's reporting something)

sure, that the "old" folder "pfSense" is now the root of your server?


http://repo.domain.tld/xmlrpc.php
http://repo.domain.tld/xmlrpc/
http://repo.domain.tld/packages/

(and so on)

cmb

Oh, yeah the base URL also changed when we moved from www.pfsense.com to packages.pfsense.org, 2.1.1 and later do not look in /pfSense/ by default for packages, rather in the root.

Hobby-Student

@cmb:

Oh, yeah the base URL also changed when we moved from www.pfsense.com to packages.pfsense.org, 2.1.1 and later do not look in /pfSense/ by default for packages, rather in the root.

Could this info please be added to the wiki?

My advice is to ignore doktornotor. He claims to be trained as a lawyer, but seemingly the only benefit he gained from law school was learning to act poorly in public.

The fact that he doesn't practice what he learned should give anyone pause.

As cmb related, we moved the repositories to their own server. Anyone running an official build likely followed without noticing.

We never signed up to supporting custom repos, etc.

doktornotor

@gonzopancho:

My advice is to ignore doktornotor. … We never signed up to supporting custom repos, etc.

Where's the -tools repo? Will you finally either publish that or stop misadvertising this as open-source? Perhaps FTC might be interested as well. ::)

As I've explained elsewhere, I don't respond to doktornotor or other abusive asshole like him (her? it?)

doktornotor

Where's the -tools repo?