Cyberpanel delete all files and directors public_html

[ricardojds]

Ok is the cyberpanel installation is from 2nd March makes sense, the bug was corrected last week, (dont kill the messenger the revisions management on the version control is bad at the moment)

The trigger that deleted the files was the out of disk space.

The issue was that when a backup failed, it deleted the files(the worst scenario possible for an IT guy).

@edwardm

@usmannasir can you point me to where this command is called, this is probably why the unfinished backup folder is not deleted, as a mention, this ca mean that it could be also some other situation where it can still happen.

[edwardm]

@MyIDKaTePe I’m sure it can be recreated but it’s not something I aim to do. dazburn just chimed in to clarify that the issue is still present in an up-to-date version of CyberPanel despite the staff saying otherwise and I just added in my findings. Neither of us came here to ask for help, we’re just saying that we’ve experienced the same bug that OP reported.

If it was actually only fixed last week as per @ricardojds’s comment then it makes sense, however we appeared to be running the latest version this morning and were greeted by a “Your CyberPanel is up to date” message on SSH login.

[MyIDKaTePe]

@edwardm

it’s not something I aim to do

at least you can help cyberpanel going better…
and try to report the problem you had.
who knows…

but it’s only if you sure that cyberpanel delete * except wp-content

[ricardojds]

@edwardm

@usmannasir

Quick note: String concact for OS command need some sanitizing and at least Quotes. does anyone knows some tool or technique for this?

[edwardm]

@MyIDKaTePe

but it’s only if you sure that cyberpanel delete * except wp-content

It didn’t delete everything except wp-content, it deleted everything including wp-content and then wp-content was recreated (as an empty shell) by an automatic script that needed to make a folder inside it.

If you run mkdir -p wp-content/something/something-else it will create all the parent directories for your innermost one.

[MyIDKaTePe]

@edwardm

It didn’t delete everything except wp-content,

@dazburn

Overnight last night is when everything disappeared at 00:30

ok,hope your problem will get solved soon

[MyIDKaTePe]

@edwardm

If you run mkdir -p wp-content/something/something-else

why you have process than run this ?
if public html already empty

well i hope your problem will solved soon

[dazburn]

The main point I came to make is that this bug had the potential to destroy an entire business for someone who didn’t have any other backups except Google Drive installed.

Thankfully, we’re not complete amateurs, but there is no way I could recommend Cyberpanel to anyone if such a major error and deletion of all site files could even be a possibility, bug or no bug.

@ricardojds thanks for the note about 2nd March installation. Can someone advise in simple terms how to update Cyberpanel then? Should we be installing the dev version because at the moment our server is showing it’s using 2.1 Build 1 though, not Build 2.

[ricardojds]

@edwardm

@edwardm @dazburn this log line is in the syslog?

[ricardojds]

02 - Upgrading CyberPanel

Upgrading CyberPanel The following command can be used to upgrade to the latest version. sh <(curl https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh || wget -O - https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh) If using a sudo user rather than root, try this: sudo su - -c "sh <(curl https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh || wget -O - https://raw.githubusercontent.com/usmannasir/cyberpanel/stable…

Proceed with caution

FIY i’m not part of dev team i just need a good hosting manager tool and this project beeing opensource and Python based, its a match for my needs and skills

[usmannasir]

@ricardojds

I’ve confirmed both cases after my fix. public_html is not deleted now, these guys may have v2.1.2 but they will not have the latest code.

Be sure to upgrade.

[nick.chomey]

@usmannasir

This is yet another example of why it is MISSION CRITICAL, TOP PRIORITY to improve the versioning system before you work on anything else.

We currently don’t receive any notification that there have been minor updates, so most people have no idea that they need to do so. This is even more urgent when you push tiny updates to fix CATASTROPHIC bugs, such as this one.

It seems completely clear that you should be making proper use of the 2.1.X for all of these - each minor commit should result in the final digit incrementing. It can go to 2.1.99999999 if needed. And then when a major feature is added, it moves to 2.2.0. And when there are breaking changes, it moves to 3.0.0. This is basic, standard practice.

If this makes your development/git workflow more difficult, so be it - it doesn’t matter compared to this. Though, given that this is standard practice, I don’t see how it could be difficult to manage. You’ll just have to adapt your workflow. There is no other choice.

Again, someone nearly lost their entire business because of this bug. Moreover, how many servers and businesses are currently running on a version of 2.1.2 that doesn’t have this fix (let alone all the other fixes from the past 6 months since 2.1.2 was released)? Thousands? Tens of thousands? More? All of your efforts to improve the security and stability are irrelevant if people aren’t made aware until an official version comes out every 6-12 months…

It would be completely unforgivable if you don’t urgently take the appropriate steps (detailed above) to fix this problem once and for all.

@die2mrw007 @shoaibkk @asma, I’m copying you here to make sure you are aware and that you can put your energy towards supporting Usman in urgently making this crucial change

[MyIDKaTePe]

@nick.chomey

TOP PRIORITY to improve the versioning system before you work on anything else.

i always vote-up and always agree with this…

[ricardojds]

One quick fix is using

root@server:/usr/local/CyberCP# git rev-parse --short HEAD
e6ed5094

becoming the version 2.1.2.e6ed5094

[nick.chomey]

How is this different/better than running the upgrade script?

Also, that’s an old commit - there’s a newer one related to this bug since then

Commits · usmannasir/cyberpanel (github.com)

Or, are you saying that the “fix” was not a fix?

[ricardojds]

@usmannasir i’m woried with this log line

@edwardm

Remember that when i was digging it was the print function that was causing the issue.

why whould some print command send the string to be used as a parameter on a rm -f command?

This means that with the newest version it is beeing called an command like this:

/usr/bin/rm -f Failed to run cp command during backup generation.

If there is somewere else another thing like this, cyberpanel may be vunerable to sheel injection that will be run as root, this is a huge security risk to be taken light

[nick.chomey]

Ok, thanks. I dont really understand, but take your word for it.

So, the most recent fix is not a fix. But the commit (e6ed5094) that uses copytree works fine and doesnt delete anything when there is a disk space or permissions issue?

[ricardojds]

ignore e6ed5094 this is from my dev server that is not up to date

[nick.chomey]

Ok, so is there a commit that satisfies this issue? Or does it still need Usman’s attention?

[ricardojds]

two known scenarios where fixed with the change of the line 378 with commit 6e40f53

usmannasir/cyberpanel/blob/3dcc57e82ed78dd13a7d47f50d5c13c92602df45/plogical/backupUtilities.py#L378

The thing that is worrying me is that the string passed to the exception, according to the log line shared, is being used in an rm command. this is another thing we need to checkout