Panilux, is a new generation Linux control panel. Built in Nginx support!

[rdn]

Panilux, is a new generation Linux control panel designed having in mind end users. Panilux allows you to control your servers in a fast and secure maner. Performance, using the latest web, email and ftp services Panilux gives you a full control of your domains. User Interface, simple and yet powerfull. Even the new users can easily grasp the concept. Security, you can securily access your private control panel using a valid SSL.

Performance
Supporting Nginx and PHP-FPM, Panilux is designed to deal with the C10k problem!

More info: https://www.panilux.com/

 

[TPerry]

And is a BETA. I personally don't think I'd place my production server at the mercy of BETA software. Might be fun to play with though.

 

[rdn]

I don't think it's beta.
Development started 2011 I think.
It's pretty stable on my test VPS.

 

[rdn]

Development started 2011 I think.

I think 2013, based on https://www.linkedin.com/company/panilux

 

[TPerry]

I think 2013, based on https://www.linkedin.com/company/panilux

I'm basing off of this

 

[rdn]

Maybe the site is the one on beta .

 

[TPerry]

Oh, and another thing.. it's restricted to a Redhat/CentOS based system

root@bigbore:/home/tracy# bash <(curl -Ss https://update.panilux.com/download/install.sh)
Error: /etc/redhat-release was not detected

 

[Slavik]

Oh, and another thing.. it's restricted to a Redhat/CentOS based system

Good, the sooner Debian can die the better

 

[Mike Edge]

Oh, and another thing.. it's restricted to a Redhat/CentOS based system

What else is there?

 

[TPerry]

What else is there?

A much better, more up to date OS that goes by the name Debian, or it's big cousin Ubuntu.

Good, the sooner Debian can die the better

I run a few CentOS VPS's.... and honestly, I hate them. If it wasn't for the fact I wanted to get exposure to them I wouldn't have any.
And I can't tell you exactly what it is about it that I don't like.. it's just one of those undefinable "things".

 

[Slavik]

A much better, more up to date OS that goes by the name Debian, or it's big cousin Ubuntu.


I run a few CentOS VPS's.... and honestly, I hate them. If it wasn't for the fact I wanted to get exposure to them I wouldn't have any.
And I can't tell you exactly what it is about it that I don't like.. it's just one of those undefinable "things".

I feel the same about Debian

 

[TPerry]

I feel the same about Debian

Well, the other reason I prefer Debian/Ubuntu is that Ubuntu is a heck of a desktop distribution also. The other major complaint I had with it was that you have to either hunt down esoteric repositories for some stuff or you compile yourself - which then makes updating a real pain the keister.

 

[D.O.A.]

Just looking through the demo https://demo.panilux.com:1453/ feature wise it's kinda like webmin with modules, except webmin is better

 

[TPerry]

Maybe the site is the one on beta .

Usually when you see this, it is a pretty good indicator it's in a BETA (or not a full release) stage unless they have a weird numbering strategy.



Another pretty good indicator is it's not fully prime time ready (not necessarily the version, but the fact that it doesn't fully set it up and that it is using a deprecated mysql extension on it's default install - not mysqli).

 

[Floren]

A much better, more up to date OS that goes by the name Debian, or it's big cousin Ubuntu.

It's time to grow up and get out of Debian's little toys sand box. I was reading this blog entry, recently. I think is been a long time I did not have such a good laugh at the arguments presented by author.

 

[Sheratan]

Talking Debian vs CentOS/RHEL is like who is better, Real Madrid or Barcelona.

 

[TPerry]

It's time to grow up and get out of Debian's little toys sand box. I was reading this blog entry, recently. I think is been a long time I did not have such a good laugh at the arguments presented by author.

Actually it's time for CentOS to get out of the '90s.

My arguments for it.. it's what I'm familiar with, it works and I don't have to spend time compiling source for anything (which I have had to do a time or two on CentOS - I have better things to do with my time than that - I do have a life) and I don't have to worry about missing dependencies that I've come across several times on CentOS installs. It also appears that a some of what he is talking about goes back to a desktop environment (why do you need MP3 codecs on a server really?). I don't think a lot of folks use CentOS in a desktop environ do they?

And until recently, there was no easy upgrade path between versions with CentOS. It required a fresh install (back to the 90's again). The argument I heard was "well, you need to make sure the code and configs are all on the same level". My argument is that the upgrade process should do that for you. Not everybody eats/breathes/sleeps Linux, and upgrades were a major issue with CentOS.

And YOU may not agree with his "arguments" but for him and his settings they may be valid.
I do know (like I said above) that I ran into dependency problems in a base install of CentOS that should really never have happened .I think it was with the PHP stack and some of the PECL's - I don't remember exactly what it was but it happened to 2 of the of the 3 I set up and then I was contacted by another party that was having problems and it was the same issue with them also.

 

[Floren]

I don't have to spend time compiling source for anything (which I have had to do a time or two on CentOS

In 15 years time I use Linux, I NEVER stumbled into a dependency issue on RHEL.

And until recently, there was no easy upgrade path between versions with CentOS.

The fact you (and others) are preferring a Linux OS major release upgrade instead of a clean install raises a lot of flags to myself. If you don't know why, there is no point in explaining. There is a reason why the smart minds at Red Had avoided this approach for years. Even now, I will never upgrade a major release and always perform a clean install.

I think it was with the PHP stack and some of the PECL's

That is because you were trying to something that other 99.9% of RHEL users base have no interest on doing so. I'm part of that 0.1% group also and that is why I created the AXIVO repository. Not everyone wants to use libmemcached, for example.

 

[TPerry]

In 15 years time I use Linux, I NEVER stumbled into a dependency issue on RHEL.

I'll see if I can find what it was again. Had to do with installing one of the PECL's and that some of the libraries were an older version (specifically had to do with upgrading the PHP to 5.6 series if I remember correctly.

The fact you (and others) are preferring a Linux OS major release upgrade instead of a clean install raises a lot of flags to myself. If you don't know why, there is no point in explaining. There is a reason why the smart minds at Red Had avoided this approach for years. Even now, I will never upgrade a major release and always perform a clean install.

Really... and now suddenly the support it because it suddenly became good? I call ********. They didn't provide an upgrade path because of other reasons. That's like saying that every time you upgrade a Windows server you have to fresh install. Idiotic.

That is because you were trying to something that other 99.9% of RHEL users base have no interest on doing so. I'm part of that 0.1% group also and that is why I created the AXIVO repository. Not everyone wants to use libmemcached, for example.

Really? They have no desire to run the latest PHP and use all the features of it?
I'll find that error and update this post shortly.

EDIT:
This is similar to one of them

Setting up Update Process
Package php54-common-5.4.22-1.ius.el6.x86_64 is obsoleted by php-common-5.5.7-1.el6.remi.x86_64 which is already installed
Resolving Dependencies
--> Running transaction check
---> Package php-pecl-zip.x86_64 0:1.12.3-1.el6.remi.5.5 will be obsoleted
--> Processing Dependency: php-pecl-zip(x86-64) for package: php-common-5.5.7-1.el6.remi.x86_64
---> Package php54-common.x86_64 0:5.4.22-1.ius.el6 will be obsoleting
--> Finished Dependency Resolution
Error: Package: php-common-5.5.7-1.el6.remi.x86_64 (@remi-php55)
Requires: php-pecl-zip(x86-64)
Removing: php-pecl-zip-1.12.3-1.el6.remi.5.5.x86_64 (@remi-php55)
php-pecl-zip(x86-64) = 1.12.3-1.el6.remi.5.5
Obsoleted By: php54-common-5.4.22-1.ius.el6.x86_64 (ius)
Not found
Available: php-common-5.4.22-1.el6.remi.x86_64 (remi)
php-pecl-zip(x86-64) = 1.11.0
Available: php-common-5.4.23-1.el6.remi.x86_64 (remi)
php-pecl-zip(x86-64) = 1.11.0
Available: php-pecl-zip-1.12.2-2.el6.remi.5.5.x86_64 (remi-php55)
php-pecl-zip(x86-64) = 1.12.2-2.el6.remi.5.5
Installed: php-common-5.5.7-1.el6.remi.x86_64 (@remi-php55)
Not found
Available: php-common-5.3.3-26.el6.x86_64 (centos6-base)
Not found
Available: php-common-5.3.3-27.el6_5.x86_64 (centos6-updates)
Not found
Available: php-common-5.5.6-1.el6.remi.x86_64 (remi-php55)
Not found
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

 

[Floren]

Really... and now suddenly the support it because it suddenly became good? I call ********.

They support upgrades for specific/targeted use cases only and do NOT recommend it. Call them to find out why, or inquire a reliable source, not a novice source.

They didn't provide an upgrade path because of other reasons.

Please enlighten us and tell us why.

Setting up Update Process Package php54-common-5.4.22-1.ius.el6.x86_64 is obsoleted by php-common-5.5.7-1.el6.remi.x86_64 which is already installed

Why do you use repositories that are flagged by CentOS? No wonder you get errors. You are using deprecated packages outside CentOS/RHEL supported list and you complain...