Discussion:
[PacketFence-users] Problem with ZEN 7.0
Hans Johnson
2017-05-07 05:28:30 UTC
Permalink
Hi Everyone,

A couple of issues… First, the copy of ZEN 7.0 that’s currently up on the website won’t deploy, at least from vcenter 6.5 (throws an error related to the XML file in the ova). It did, however deploy from the old fat client, deploying to one of my hosts that is still running vmware 6.0.

Now for the more annoying problem I’m facing:

I’m working on standing up packetfence ZEN 7.0, and have run into a frustrating problem.

I pretty much had everything working in a test environment, the switch was doing MAB, I could log in, the port would get assigned to the correct VLAN, everything was great.

The last step was to swap out the self-signed certificate that shipped with the system for our organization’s wildcard. I moved the certificate onto the server, swapped out the configuration files, and rebooted. I just dropped them in in place of the original .key and .crt files, and also pointed to the intermediate certificates.

After doing so, the admin interface came right back up using the correct certificate. At first, I ran into a situation where the captive portal was still using the self-signed certificate. I noticed there was a .pem in there, which I removed, and ever since then the portal has refused to connect.

When I look the httpd.portal file that was generated for the portal, under /usr/local/pf/var/ it shows that it is telling it to listen on 127.0.0.1, rather than my registration VLAN. I’ve tried deleting the interfaces, restarting things, and re-creating the interfaces, and no joy. I’ve tried removing the auto-generated httpd.portal, config file, and when it’s regenerated, it sitll comes up as 127.0.0.1.

I’m pretty much at my wits end here. I would appreciate where to go from here.

Thanks!

Hans
Durand fabrice
2017-05-07 18:02:50 UTC
Permalink
Hello Hans,

haproxy terminate the ssl tunnel now, so the certificate must be
installed for haproxy and not apache anymore.

So you have to do that with your certs:

cat /usr/local/pf/conf/ssl/mycert.crt /usr/local/pf/conf/ssl/mycert.key
/usr/local/pf/conf/ssl/server.pem
Also since haproxy is in front of apache then it listen on the
registration interface.

Don't forget to restart haproxy.

Regards
Fabrice
Hi Everyone,
A couple of issues… First, the copy of ZEN 7.0 that’s currently up on the website won’t deploy, at least from vcenter 6.5 (throws an error related to the XML file in the ova). It did, however deploy from the old fat client, deploying to one of my hosts that is still running vmware 6.0.
I’m working on standing up packetfence ZEN 7.0, and have run into a frustrating problem.
I pretty much had everything working in a test environment, the switch was doing MAB, I could log in, the port would get assigned to the correct VLAN, everything was great.
The last step was to swap out the self-signed certificate that shipped with the system for our organization’s wildcard. I moved the certificate onto the server, swapped out the configuration files, and rebooted. I just dropped them in in place of the original .key and .crt files, and also pointed to the intermediate certificates.
After doing so, the admin interface came right back up using the correct certificate. At first, I ran into a situation where the captive portal was still using the self-signed certificate. I noticed there was a .pem in there, which I removed, and ever since then the portal has refused to connect.
When I look the httpd.portal file that was generated for the portal, under /usr/local/pf/var/ it shows that it is telling it to listen on 127.0.0.1, rather than my registration VLAN. I’ve tried deleting the interfaces, restarting things, and re-creating the interfaces, and no joy. I’ve tried removing the auto-generated httpd.portal, config file, and when it’s regenerated, it sitll comes up as 127.0.0.1.
I’m pretty much at my wits end here. I would appreciate where to go from here.
Thanks!
Hans
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
https://lists.sourceforge.net/lists/listinfo/packetfence-users
Hans Johnson
2017-05-07 20:23:09 UTC
Permalink
Hi Fabrice,

Thanks, that’d do it… Is it something that I missed in the documentation, or is there a way I can contribute back to the documentation so that others don’t make the same mistake I did? I was mostly following along with the quick deployment guides.

For the moment, I’m back on 6.5.1 as I could get that one up and running.

I’ll also submit a bug report regarding the problem deploying ZEN 7 under vcenter 6.5.

Thanks for all your hard work on this project. We’re a small non-profit with very limited internet connectivity, so being able to deploy something like this really helps us serve our volunteers better.

Regards,

Hans
Post by Durand fabrice
Hello Hans,
haproxy terminate the ssl tunnel now, so the certificate must be
installed for haproxy and not apache anymore.
cat /usr/local/pf/conf/ssl/mycert.crt /usr/local/pf/conf/ssl/mycert.key
/usr/local/pf/conf/ssl/server.pem
Also since haproxy is in front of apache then it listen on the
registration interface.
Don't forget to restart haproxy.
Regards
Fabrice
Hi Everyone,
A couple of issues… First, the copy of ZEN 7.0 that’s currently up on the website won’t deploy, at least from vcenter 6.5 (throws an error related to the XML file in the ova). It did, however deploy from the old fat client, deploying to one of my hosts that is still running vmware 6.0.
I’m working on standing up packetfence ZEN 7.0, and have run into a frustrating problem.
I pretty much had everything working in a test environment, the switch was doing MAB, I could log in, the port would get assigned to the correct VLAN, everything was great.
The last step was to swap out the self-signed certificate that shipped with the system for our organization’s wildcard. I moved the certificate onto the server, swapped out the configuration files, and rebooted. I just dropped them in in place of the original .key and .crt files, and also pointed to the intermediate certificates.
After doing so, the admin interface came right back up using the correct certificate. At first, I ran into a situation where the captive portal was still using the self-signed certificate. I noticed there was a .pem in there, which I removed, and ever since then the portal has refused to connect.
When I look the httpd.portal file that was generated for the portal, under /usr/local/pf/var/ it shows that it is telling it to listen on 127.0.0.1, rather than my registration VLAN. I’ve tried deleting the interfaces, restarting things, and re-creating the interfaces, and no joy. I’ve tried removing the auto-generated httpd.portal, config file, and when it’s regenerated, it sitll comes up as 127.0.0.1.
I’m pretty much at my wits end here. I would appreciate where to go from here.
Thanks!
Hans
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
https://lists.sourceforge.net/lists/listinfo/packetfence-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
https://lists.sourceforge.net/lists/listinfo/packetfence-users
Loading...