Installing EMACS

[David Dyer-Bennet]

Not a FreeBSD user of any experience. I got far enough to try pkg_add, but get:

# pkg_add -r emacs-nox11
Error: Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/emacs-nox11.tbz: File unavailable (e.g., file not found, no access)
pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/emacs-nox11.tbz' by URL
​

(The filename came from an Internet search for installing emacs on FreeBSD.)

(Emacs is the best tool I know for working with log files; it's the only thing that handles the size of log files reliably. I spent a year once reading a lot of 20MB log files on an 8MB Sun workstation, and Emacs just ate it up. Also my fingers have used Emacs for all serious editing since 1981 and they just don't adapt to other editors very well any more -- I routinely find myself six commands down some path or other before my brain processes the input from my eyes saying it's not doing what I expected.)

 

[David Dyer-Bennet]

(I.e. don't try to tell me I don't want Emacs, I will laugh rudely in your face. You may not want Emacs, which is fine, that's your choice. I do!)

 

[dlavigne]

Use the docs instead: http://doc.freenas.org/9.3/freenas_jails.html#installing-freebsd-packages. Also note its warning:

Warning: do not use the pkg_add command in a FreeNAS® jail as it will cause inconsistencies in your package management database.

 

[SweetAndLow]

You don't install applications on freenas. It's an appliance and you get it the way it comes unless you want to compile your own. Did you try emacs it might be installed already. If not you can use 'less' to look at logs. And really you should never have to look at logs once everything is set up. I haven't looked at my logs in over a year.

Also to install applications on freebsd you use pkg install. Pkg_add is the old style method.

 

[Jailer]

And search freshports before you try installing any software to ensure you are using the correct commands for the software you want to install.

https://freshports.org/editors/emacs/

 

[David Dyer-Bennet]

Emacs isn't installed already, I did try that the very first thing.

Freshports.org confirms the emacs-nox11 is one of the valid names to install.

pkg install produced equally useless results:

[root@zzbackup /mnt/zzback/local/ddb]# pkg install emacs-nox11
Updating local repository catalogue...
pkg: file:///usr/ports/packages/meta.txz: No such file or directory
pkg: repository local has no meta file, using default settings
pkg: file:///usr/ports/packages/digests.txz: No such file or directory
pkg: Unable to update repository local
All repositories are up-to-date.
pkg: No packages available to install matching 'emacs-nox11' have been found in the repositories

What I'm specifically looking for in the logs is information about a drive that's failing. I hope I don't have to do that very often, but I wanted to know more than what the gui or even the command line was telling. Also this server isn't in production yet, it's in the stage where I'm learning my way around it. Seeing what's going on in the logs is very often useful.

Less does work of course, just less conveniently.

 

[danb35]

You don't install applications on freenas.

What he said. If you want to install software, install it in a jail. Do not attempt to install applications to the main FreeNAS system.

 

[David Dyer-Bennet]

Weird, the docs say very clearly *not* to install applications in a jail since that will corrupt the package database.

And "application" may be the key here -- emacs is a utility, not an application. Which means not having it available everywhere is not useful. Can I even *see* the system logs from a jail? Can I ssh into a jail? [Okay, I checked, it's possible to turn on SSH in each jail individually, so "yes" there. Still not sure about seeing the system logs though.]

 

[SweetAndLow]

Weird, the docs say very clearly *not* to install applications in a jail since that will corrupt the package database.

And "application" may be the key here -- emacs is a utility, not an application. Which means not having it available everywhere is not useful. Can I even *see* the system logs from a jail? Can I ssh into a jail? [Okay, I checked, it's possible to turn on SSH in each jail individually, so "yes" there. Still not sure about seeing the system logs though.]

What the heck are you trying to do? If you want emacs in a jail install it with 'pkg install emacs' if you want it in the base freenas environment you can't do that and need to just use less, more, cat, vi or what ever else is installed with the base os.

 

[cyberjock]

I'll try to keep this short and sweet.

• FreeNAS is an "appliance-like" OS. You do not add anything to FreeNAS, ever. It's not designed to do that, it can't do that, and you'll really screw things up if you try to make it work. (hint: If you want to view logs in emacs you can stop reading my post right now because the rest is going to get more depressing).
• If you want to install anything (emacs is an application... you're splitting hairs if you want to call it a utility and it doesn't change the facts of the discussion) then you need to install them inside a jail.
• Installing programs requires you to use either pkg-ng (not the older package system) or compile from the ports trees. pkg-ng is typically easier to get working for new users because you can get a working program installed in a single command without the risk of compiling going very badly from ports.

If you want to add emacs, you are welcome to provide a pull request in github for FreeNAS and a dev will probably add it. If you aren't familiar with that, you are welcome to put in a feature request at bugs.freenas.org. Considering that the CTO of iXsystems likes Emacs and its still not in FreeNAS, I wouldn't have high hopes of a feature request getting developer resources put towards it (hence I recommended the pull request first).

 

[David Dyer-Bennet]

I'm trying to use powerful tools I'm comfortable with to manage the system, okay?

 

[pirateghost]

I'm trying to use powerful tools I'm comfortable with to manage the system, okay?

You shouldn't be managing the system from the command line. It seems this is a recurring theme for you.

Want to view your logs in EMACS? ship the logs over to another workstation on the network and have at it.

 

[David Dyer-Bennet]

Hmm; as I understand "pull requests", that route requires me to fork the repository and put the change in myself. Might be possible but would be quite a learning curve (I'm a software developer professionally, but just encountering the build environment of a new project is usually kind of a lot of time). Can't hurt to put in the feature request, I suppose.

 

[David Dyer-Bennet]

You shouldn't be managing the system from the command line. It seems this is a recurring theme for you.

I know Solaris ZFS well, the GUI here not so well. And I keep running into things the GUI doesn't actually do -- like give me enough information to identify a failed disk (in fact, it didn't tell me a disk was failed at all, after the reboot, but zpool status did). So yeah, I have no particular affection or trust in the GUI.

Since the command line tools are the basic ZFS tools, and anything the GUI does goes through them (or the libraries they use)....

 

[pirateghost]

I know Solaris ZFS well, the GUI here not so well. And I keep running into things the GUI doesn't actually do -- like give me enough information to identify a failed disk (in fact, it didn't tell me a disk was failed at all, after the reboot, but zpool status did). So yeah, I have no particular affection or trust in the GUI.

Since the command line tools are the basic ZFS tools, and anything the GUI does goes through them (or the libraries they use)....

Except when the GUI modifies the database (like managing users), the command line doesn't.

If you aren't getting notifications of failed disks, you have an improperly configured setup. Maybe from all your mucking around in the command line doing things you shouldn't do on an appliance?

 

[David Dyer-Bennet]

I'm getting notification of the failure, but no way to identify the disk -- I get the label of it, which doesn't let me find either the serial number or the controller port it's attached to other than by going into the shell and using glabel (that I've found so far).

 

[SweetAndLow]

You have lots of other issues and Freenas probably isn't what you should be using. If you don't use the GUI then you should not be using freenas and just use FreeBSD. You should get lots of notifications that a disk is failing and then when it fails you should get more notifications. The gui has the S/N for each drive so you know which one to pull out and will show you which one is dead.

 

[cyberjock]

Sadly, you must be doing something wrong, not know how to use the GUI to your advantage, or have things misconfigured. Every time I have a disk fail (aside from when a disk fails so catastrophically that it is no longer even detected by the system) going to the CLI is something I never had to do.

If you have no faith in the WebGUI, you should probably switch to FreeBSD itself. FreeNAS, as an appliance, expects you to do virtually everything from the WebGUI, API, etc. The CLI is basically a "do everything at your own risk, and be warned that you may reboot and be very sorry with the consequences" situation. We can't block the CLI, but the gloves come off when you go to the CLI. Many, many users have shot themselves in the face by swearing off the GUI and using the CLI, and sometime months later they realize they screwed up badly and many, many man-hours are going to have to be spent to undo all of the problems that were created.

Honestly, the more I read from this thread, the more I get the impression you're better off with FreeBSD. FreeNAS is what it is, because of the WebGUI. If you aren't akin to using it, you've got a few options:

1. Pull requests in github.
2. Feature requests/bug reports for the problems.
3. Accept it as it is.
4. Use something else.

As you are wanting to do things that FreeNAS provides no good option (ie using emacs) you are already working outside the designed criteria, and FreeBSD sounds like a much better fit for you.

Even myself, having been using FreeNAS for a few years, it's something that has its limits. It felt limitless in options when I was learning it, but it does have its limits. That's just the consequence of using an appliance. I can't wash my laundry in my dishwasher. My dishwasher won't vaccum my floor. But it does clean dishes, and it does a good enough job at that to keep it around.

 

[David Dyer-Bennet]

Well, I'm coming from Solaris, where it's all command line, and I know the ZFS commands well. The GUI is confusing, especially because it renamed a lot of things (it calls pools "volumes", and "detaching" a device has become code for several different operations, and so forth). And the manuals keep showing going into the command line to do things, or to look at things. And there seem to be extra levels in the hierarchy created, which confuses me still.

I do know the user stuff doesn't work from the command line (the database issue). I'd suggest that replacing those utilities, so that attempting to use them warned you of the problem, might reduce the user screwup rate.

In general, everybody with Unix experience knows that the command line is "real" and any GUI is a thin veneer plastered over it that's less capable and not very complete.

Going to straight FreeBSD has crossed my mind, certainly. I used to know it better, but long ago (mid 1990s); I was news admin for a few sites, and for some of them I built and managed INN on FreeBSD.

 

[cyberjock]

What you said just reinforces the recommendation to go to BSD. FreeNAS is designed for those users that have little or no CLI experience and are wanting to use ZFS without needing the year or two to really get comfortable with using FreeBSD from the CLI and be familiar with what you are looking at, what problems are occuring, how to fix them, etc.

It *really* sounds like you are better off with FreeBSD as you don't need the proverbial "training wheels" to get familar with the CLI.

Yes, some things are named poorly. I've made that argument before, but since FreeNAS has been using them for longer than I've been around, convincing the "powers that be" that the naming should change is a hard argument to make.

The manual does have recommendations for troubleshooting steps to look at from the CLI. But when it comes to actually making changes to the OS, I don't think it ever asks you to run a command that actually changes the configuration. Most is poking around with things like testing ssh tunnels for Replication, viewing SMART output from smartmontools, and other things that don't change your configuration.