SOLVED accidentally deleted nginx from root...

[neatfreak]

Hello

I did something really stupid, i thought i was still in the jail userland but since i restarted the jail it kicked me out of the jail userland so after i tried to follow up on the guide i typed in pkg remove nginx.
it delete something of the size of 744KB so i thought what if i just type in pkg install nginx it wants to install 350MB so im not sure if i should do this.

can please somebody please help me. Im sorry for posting something like this is what happens when somebody has to multitask while following a guide.

sofar the jails still work but the main WebGUI doesnt work anymore.

Code:

[root@freenas] ~# pkg remove nginx
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        nginx-1.6.2,2

The operation will free 744 kB.

Proceed with deinstalling packages? [y/N]: y
[1/1] Deleting nginx-1.6.2,2:  52%
pkg: cannot stat /usr/local/man/man8/nginx.8.gz: No such file or directory
[1/1] Deleting nginx-1.6.2,2: 100%

 

[danb35]

Do a clean install, upload a saved copy of your config file, and you'll be good to go.

 

[DrKK]

Nonononononoononoono.

Just reboot the system. The entire system dataset is always reconstituted at boot. Come on guys.

 

[danb35]

You're saying that rebooting the system will fix the removal of one of the packages in the base system? Because that doesn't seem to be happening for me, at least not to the point of making the system usable again. Using a test VM with the latest 9.3-STABLE build, I did:

• pkg remove nginx
• reboot
• Attempt to browse to the web GUI

The result is a Chrome error page saying ERR_EMPTY_RESPONSE. It does appear that the nginx package is installed after the reboot (which I hadn't expected), but apparently other things aren't.

 

[DrKK]

Well something is definitely wrong then, or, I had a fundamental misunderstanding. I thought that everything about the FreeNAS system partition was reconstructed upon boot, every time you booted, and this is why, for example, you can't change various .conf files without jumping through significant hoops.

I don't have time to test it out now, but surely someone like @cyberjock or @SweetAndLow can shed more knowledgeable light on this if I somehow have it wrong.

 

[jgreco]

No, the base system is now ZFS. This means things work a little differently and my offhand guess is that yes, trying to remove the package might indeed damage the base system since the base system is no longer read-only.

 

[jgreco]

Do a clean install, upload a saved copy of your config file, and you'll be good to go.

Voted "correct answer."

 

[DrKK]

No, the base system is now ZFS. This means things work a little differently and my offhand guess is that yes, trying to remove the package might indeed damage the base system since the base system is no longer read-only.

Well, I think we should understand this a little better. If I think of it, I'm going to play with the system a bit and find out what's going on. It's still certainly the case that the configurations in /etc and /usr/local/etc or whatever are recreated with a boot...

We should probably put something in there so users can't accidentally do "pkg delete"...some kind of warning: "WARNING: You are about to perform a pkg delete in the FreeNAS appliance. This is generally a super bad idea, and you should not do this unless you know what you're doing." etc.

 

[jgreco]

Well, feel free. I've gotten tired of submitting bug reports that ultimately get ignored or slept on forever. I'm not sure exactly how it'd work though. Since there's no longer a primary and backup partition strategy and snapshots are used instead, it may not be practical to keep large portions of the filesystem read-only.

 

[Ericloewe]

Since FreeNAS 10 uses a somewhat custom shell, such a warning sounds like something they'd leave for later. I sense great reluctance in messing with big stuff in 9.3.

 

[jgreco]

"custom shell"... grumble grumble... (**bad Nexenta memories**)

 

[Ericloewe]

"custom shell"... grumble grumble... (**bad Nexenta memories**)

The devs tend to agree with you, for now:

https://bugs.freenas.org/issues/10616

 

[danb35]

Couldn't they just 'pkg lock' the appropriate packages?

 

[jgreco]

I suppose I should spin up the FreeNAS 10 VM and update it and actually see what's there today. I'm not necessarily opposed to a well designed appliance CLI, but usually the growing pains on the first few rounds of attempts make for awkwardness.

 

[jgreco]

Couldn't they just 'pkg lock' the appropriate packages?

I think users are expected to not be messing around with the package manager to begin with. You're not supposed to be adding or deleting packages.

 

[danb35]

Granted, but it seems that pkg lock would tend to avoid the problem.

 

[jgreco]

So would the user not running package manager commands.

 

[rogerh]

So would the user not running package manager commands. :)

Fair enough, but accidents happen; the OP thought he was in a jail shell! Reducing the likelihood of accidents is possibly one way that the objectives of an appliance differ from those of a unix-like OS.

 

[danb35]

Indeed, but can the devs do anything about that?

I'm all for the user bearing the consequences of his error, but I also think that if the devs can make a change that (1) prevents or mitigates that error, and (2) does not break the rest of the system, that should be considered. A couple of candidate changes might be (a) remove the pkg binary from the base install, or (b) do 'pkg lock' on the base system packages. I don't know enough about the FreeBSD package system to know the ramifications of (b)--it seems it would prevent inadvertent removal, but I don't know what else (if anything) it might break. I'd guess that (a) is probably too drastic of a change.

@neatfreak made a mistake, and fortunately for him, there's a fairly straightforward path to fix it. But if the system can do something to keep future users from making that mistake, shouldn't that be considered?

 

[jgreco]

Fair enough, but accidents happen; the OP thought he was in a jail shell! Reducing the likelihood of accidents is possibly one way that the objectives of an appliance differ from those of a unix-like OS.

Yes, but then you're talking about mitigating all sorts of "oops."

"Oops, I typed rm -fr /"

"Oops, I typed killall foo outside the jail"

etc. I'm guessing that the idea in FreeNAS 10 of introducing a specialized CLI is in part to help address some of that. But I can do more dumb UNIX tricks in a minute than you can fix with a month of coding. And I'm not even that imaginative.