Some Don'ts After Installing CyberPanel!
Hello!
After installing CyberPanel there are somethings that you don't want to do for having a smooth experience.
Don't upload files via SFTP
When you upload files via sftp they are owned by root, and CyberPanel runs each account through its own user, so once you have uploaded content via root, you might start getting permissions errors. More details can be found here.
Even though file manager now has one-click fix permission button to get rid of this issue, but this is still not a recommended way to upload content.
The recommended way is to use File Manager and FTP. They both use the same user as which scripts are executed for a particular site.
Note: As soon as files are owned by root, file manager may not be able to access and you will start having issues.
Do not remove the Example vhost
Example vhost contains files to run File Manager, so if you delete or make any changes to example vhost , File Manager will stop working.
File Manager
You might notice that each virtual host contains this configuration
context /.filemanager {
type NULL
location /usr/local/lsws/Example/html/FileManager
allowBrowse 1
autoIndex 1
accessControl {
allow 127.0.0.1, localhost
deny 0.0.0.0/0
}
addDefaultCharset off
}
This needs to be present for the file manager to work, once this is deleted file manager will stop working.
MYSQL
After CyberPanel installation 2 instances of MYSQL are started, one of these instances runs CyberPanel which listens on port 3307.
The normal mysql instance runs on port 3306. If for some reasons you are going to change these ports, you need to update CyberPanel settings file to reflect these changes.
Settings file is located at /usr/local/CyberCP/CyberCP/settings.py
In this file you will find:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'cyberpanel',
'USER': 'cyberpanel',
'PASSWORD': 'cyberpanel',
'HOST': '127.0.0.1',
'PORT':'3307'
},
'rootdb': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'mysql',
'USER': 'root',
'PASSWORD': 'cyberpanel',
'HOST': 'localhost',
'PORT': '',
}
}
You can see there are two ports mentioned, 3307 and 3306, so incase you have changed these default ports make sure to change them here respectively and than do:
systemctl restart gunicorn.socket
MYSQL Password
If you change MYSQL root password also update this file with updated password:
/etc/cyberpanel/mysqlPassword
This article is still a work in progress.
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
I suggest removing this section:
Without it, the attacker still can not access the filemanager without login.
If you use it, when users want to use reverse proxy will cause error filemanager
It applies to
.filemanagercontext only, without this file manager api can be accessed.I mean you should allow from all IP
File manager API will be exposed to public then.
Did you mean, that is the only protection method of "file manager api"?
So if I attacked a share hosting site on the CyberPanel server, through which I could contact the "file manager api" (because I was querying from localhost), and "file manager api" did not ask me Any authentication as long as I query from localhost?
So, can I access Filemanager of any website hosting share on CyberPanel if I own one website located on the same server?
And when you enable the "Use Client IP in Header" function, you will also be prevented from accessing Filemanger
Failed to load resource: server responded with a status of 403 (Forbidden)
This issue is now resolved in CyberPanel 1.6.3. You can upgrade using this guide: https://forums.cyberpanel.net/discussion/85/how-to-manually-upgrade-downgrade-cyberpanel
SSL Certs are stored at
We have Administrators and Normal users only, Reseller is not available now. You should be able to create administrators and normal users.
From website control panel you can also save your customs SSLs too without going into command line.
Still can not access Filemanager if you use a reverse proxy as Cloudflare, CDN, Sucuri...
The update addresses the security issue in the File manager, I do not understand your issue?
When you use a reverse proxy such as Cloudflare for a domain,
Openlitespeed blocks incoming IPs from Cloudflare or Real IPs of visitors to Filemanager because of the following configuration:
Because Openlitespeed recognizes the real Ip of the visitor (It is not 127.0.0.1):
I want to ask how the mechanism upload a file by Filemanager like?
You do not upload the file directly (size 100MB or more) to a direct IP of the server?
Instead, it will not upload directly to the IP of the server but via a Domain name, For example: web7.example.com/.filemanager/,
So you will upload the file through the Reverse proxy of the domain: web7.example.com, I think this is a bad idea. Because I go directly to the server's IP https: //x.x.x.x: 8090 but when I upload a file it goes through a Reverse proxy?
The file will go from me -> to the Cyberpanel Server IP -> and to the Reverse Proxy Server (Because domain is using Reverse proxy) -> then back to the Cyberpanel Server IP ...
This is disaster, I think people will always want to upload files directly from them to the IP of the server.
accessControl { allow 127.0.0.1, localhost deny 0.0.0.0/0 }You can remove this part if you need since File manager does additional checks now. It is supposed to work this way to follow Suexec pattern, otherwise, if we run this as root, file and folders uploaded are owned via root and there can be other security issues.
I assumed you have not removed Example vhost mapping from the listener.
virtualHost Example{Then restart OpenLiteSpeedvhRoot $SERVER_ROOT/Example/
allowSymbolLink 1
enableScript 1
restrained 1
maxKeepAliveReq
smartKeepAlive
setUIDMode 0
chrootMode 0
configFile $SERVER_ROOT/conf/vhosts/Example/vhconf.conf
}