debianized the script

[bobafetthotmail]

now it can be turned in an unsigned .deb package by

debuild -b -uc -us or in a signed package too.

If you want you can check around and place your email instead of mine.

Please check that your script does not use perl components that aren't inside "perl" debian package (or its dependancies), so they can be added to the dependancies of this package.

[bobafetthotmail]

I actually cloned them from folder2ram, and adapted the relevant parts (and the folder2ram ones came from fs2ram's).

I looked at official debian mantainer docs to know what is what, and imho it's more than enough. https://www.debian.org/doc/manuals/maint-guide/index.en.html (here also available as pdf https://www.debian.org/doc/devel-manuals )

Once you created the package you can install it with a sudo dpkg -i name_of_package.deb if you have this package in the same folder of the terminal.

Or, if you have a full desktop with graphical GUI it's a double-click on it to bring up the GUI installer tool.

sudo apt-get remove name_of_package will remove it from the system (but leaves the .deb file where it was)

You probably want to write some commands for dir2ram in the package scripts, those called when the package is installed (preinst, postinst) or when it is removed (preremove, postremove). So that your script can be removed safely even if it was active (something I did recently to folder2ram, to allow easy and automatic updates of that package without breakage), or whatever.

Will probably port over systemd compatibility (from folder2ram to your script) in the near future, since OMV 3.0 is based on Debian jessie, and that means we have systemd and not sysvinit.

Getting stuff running natively with systemd is MUCH better/easier than relying on systemd's legacy init.d fallback (as it still does read init.d anyway).

[Reed97123]

I noted that there are some multiple copies of the same file. For example the dir2ram program is located both: /sbin/dir2ram and /debian/dir2ram/sbin

I assume that I'd only change the /sbin/dir2ram file and that the one under /debian would change automatically with the automation, but I wasn't 100% sure.

I was also curious about the systemd vs. sysvinit you mentioned. I looked it up on Wikipedia, but I still had some basic questions about how it affects folder2ram and dir2ram? Does this affect the shell scripts we place in /etc/init.d or does this change how we install on debian or with OMV? Where does this cause us to need to alter what we are doing?

[bobafetthotmail]

yes, the Debian/dir2ram contains temporary stuff created automatically by the package builder system.

It's probably better to place a "git ignore" for that folder (so it does not get loaded on git)... for now it won't hurt anyway. Will have to put that folder in the ignore list.

"I was also curious about the systemd vs. sysvinit you mentioned."

Don't know what you know so I'm starting from the beginning. Don't take it wrong, it's faster to do this than trying to find out what you know. Systemd is an init program (also sysvinit is). When the kernel has finished booting it looks for and starts the init program, then the init program starts everything else in the system.

The init program is the boss of the userspace (programs that aren't kernel or drivers), starts up things and stops other things, it is the responsible of everything that isn't talking directly with hardware.

The older ones (sysvinit and upstart) are pretty dumb/simple themselves and the "intelligence" is in the initscript, so you had to write large, slow, mostly-boilerplate scripts in /etc/init.d, Systemd moves all the intelligence inside the init system, and replaces initscripts with plain config files.

With systemd you can simply have your stuff relatively verbose on stdopt and all its output is neatly logged inside a binary database that makes very easy/fast to sort the output and find all the output of your service (at a specific point of time, or time-period or whatever). For debugging it's totally awsum. :) With a one-liner command I get the status of my service, when it started, the last 5 lines of its stdopt output. With another one-liner you can get a graph of startup times to see what services take most time to startup and things like that.

There is also a large amount of things that systemd does and sysvinit fails horribly at, which may be useful (or not) for future features of dir2ram, or to handle correctly services that use systemd natively. Also, systemd integrates already some of the features of dir2ram by keeping syslogs in ram (by default) and keeping them at a user-defined max size, for example. So you need to handle this (if you want to). http://elinux.org/images/a/a2/Olbrich--systemd_for_embedded_linux_challenges_and_opportunities.pdf http://events.linuxfoundation.org/sites/events/files/slides/ELC_systemd_0.pdf

Anyway, back to businness: systemd reads "unit files" (a simple text file) that look like this (the one I'm using for folder2ram)

[Unit]
Description=folder2ram systemd service
DefaultDependencies=no
After=local-fs.target
Before=basic.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/folder2ram -mountall
ExecStop=/sbin/folder2ram -umountall

[Install]
WantedBy=basic.target

It is tidy and nicer than an initscript.

I had issues because for some unknown reason my script was placing a "feff" inside the unit script and systemd was complaining, but that's probably my fault. http://www.fileformat.info/info/unicode/char/feff/index.htm (a guy in the latest closed folder2ram issue thread told me about that, and indeed he was right)

"Where does this cause us to need to alter what we are doing?"

systemd does its best to read initscripts in init.d and start them at the right time, and it usually works fine. But if you do it natively with a unit like the one above, it is one less thing that can break. see here for a (slightly) more detailed explanation https://www.turnkeylinux.org/blog/debugging-systemd-sysv-init-compat

There is also the PR factor, and the fact that systemd is becoming the standard everywhere pretty fast, so if you work with linux you will find useful to know well systemd anyway.

Since it is actually pretty easy, as it is little more than copy-paste from folder2ram, I'm probably able to pull it off myself. No worries, I can handle this.

Like in folder2ram, I'm thinking about adding a different mode, so the script can run with init scripts or with systemd natively depending on user choice.

[Reed97123]

Great information, thanks!

My time right now is limited as I am preparing for and traveling to Costa Rica for about a week. Once I get back I'll get back into this.