Diversion Diversion - the Router Ad-Blocker

[bengalih]

I've got some quick questions (since I'd rather not uninstall and reinstall a bunch of stuff to start finding the answer).
1) Is Diversion's Entware install responsible for linking /opt to the entware directory, or is this something Entware itself does?
2) Is this mapping critical? I.e. if we were to remove this mapping, would Diversion fail to function?
3) Where is this mapping done, and is it a one off or redone on each boot?

thanks!

 

[cmkelley]

I've got some quick questions (since I'd rather not uninstall and reinstall a bunch of stuff to start finding the answer).
1) Is Diversion's Entware install responsible for linking /opt to the entware directory, or is this something Entware itself does?
2) Is this mapping critical? I.e. if we were to remove this mapping, would Diversion fail to function?
3) Where is this mapping done, and is it a one off or redone on each boot?

thanks!

1) Entware does it.
2) Yes, it's critical, any installed Entware programs would fail. I'm not 100% sure about Diversion, but I think it would fail also.
3) Redone at every boot. The router filesystem, except for /jffs and any mounted USB drives, is stored entirely in memory, so any changes to the filesystem, including the link from /opt, are lost when power is removed. It reloads the filesystem from the firmware into memory at bootup.

 

[thelonelycoder]

I've got some quick questions (since I'd rather not uninstall and reinstall a bunch of stuff to start finding the answer).
1) Is Diversion's Entware install responsible for linking /opt to the entware directory, or is this something Entware itself does?
2) Is this mapping critical? I.e. if we were to remove this mapping, would Diversion fail to function?
3) Where is this mapping done, and is it a one off or redone on each boot?

thanks!

Diversion does the mapping, in /jffs/scripts/post-mount at every mounting of the device that the "entware" folder is found in. That includs booting. And it is essential for Diversion, hence my complicate procedure to do it. But it works flawless, unlike the procedure some other Entware installers use.

 

[cmkelley]

Diversion does the mapping, in /jffs/scripts/post-mount at every mounting of the device that the "entware" folder is found in. That includs booting. And it is essential for Diversion, hence my complicate procedure to do it. But it works flawless, unlike the procedure some other Entware installers use.

Oh yeah, I forgot you added it. My bad. I remembered Merlin's Entware installer in the firmware does that mapping when it installs Entware.

I'll just shut up now.

 

[thelonelycoder]

Oh yeah, I forgot you added it. My bad. I remembered Merlin's Entware installer in the firmware does that mapping when it installs Entware.

I'll just shut up now.

I too unintentially lie, spread untrue facts and have stupid ideas. We're human and not robots.

My boss and I were discussing the pros and cons of having kids today. We both have none. He recently added the 'burden' of a very likable dog to his responsabilities: Our new permanent office cleaner and Network cable muncher.
There's one thing indisputable (with this and most dogs): He's always happy to see you, no matter what.

 

[bengalih]

1) Entware does it.
2) Yes, it's critical, any installed Entware programs would fail. I'm not 100% sure about Diversion, but I think it would fail also.
3) Redone at every boot. The router filesystem, except for /jffs and any mounted USB drives, is stored entirely in memory, so any changes to the filesystem, including the link from /opt, are lost when power is removed. It reloads the filesystem from the firmware into memory at bootup.

Thanks. I have a question/debate to pose which may have been discussed before concerning what would be considered traditional/standardized use of the unix filesystem directory naming structure.

Generally, "/opt" is reserved for optional/3rd party software packages. While Entware of course falls into this category, it is not the sole optional software repository one might install on this device. I feel that claiming the entire "/opt" directory/mount point is a little aggressive.

For instance, if I want to install another application "AppX" to my system, I would generally install this to "/opt/AppX." However this location would now be the link to Entware and "AppX" directory would install alongside the other Entware root directories (e.g. "root", "sbin", "tmp", "etc",...). This would not be ideal.
I could choose to install it to "/opt/opt" which would look a bit better as Entware has no "/opt" within it's structure.

I could choose to put an /opt filestructure at the root of /tmp/mnt/flash_drive and install all my 3rd party products there.
The problem is I can never link this to /opt because Entware has already claimed it.

Ideally, I feel that entware should actually install to "/tmp/mnt/flash_drive/opt" and that /opt should link to this location and all references to Entware should be as "/opt/entware/X".
Or, alternatively, the entire flash drive should just be considered /opt.

I realize that this would likely entail some issues with a new release and upgrades, as well as changes to other scripts.
I don't expect that you will be doing this anytime soon.
However I would like to discuss why this option was chosen and if you believe me to be incorrect in my argument (it's ok to say I'm right and you won't change it...I just need to understand why it was done this way and how you expect/recommend people to deal with this situation).

I'm mostly concerned due to either Entware and or Diversion (or other scripts) wiping out the entire Entware directory on an uninstall which would also remove anything that might be in "/opt" that doesn't directly belong to Entware.

Thoughts?

 

[bengalih]

My boss and I were discussing the pros and cons of having kids today. We both have none. He recently added the 'burden' of a very likable dog to his responsabilities: Our new permanent office cleaner and Network cable muncher.
There's one thing indisputable (with this and most dogs): He's always happy to see you, no matter what.

Some of us are allergic to most animals, and thus we choose children.
My argument would be that conditional love, when earned, is better than unconditional.

 

[thelonelycoder]

Some of us are allergic to most animals, and thus we choose children.
My argument would be that conditional love, when earned, is better than unconditional.

I'm allergic to most animals hairs, some trigger no reaction others do much more. It's no big deal for me, had it since I was little.

 

[thelonelycoder]

Ideally, I feel that entware should actually install to "/tmp/mnt/flash_drive/opt" and that /opt should link to this location and all references to Entware should be as "/opt/entware/X".
Or, alternatively, the entire flash drive should just be considered /opt.

Not going to happen. Entware itself relies on it being mounted to /opt/, this is outside of my control.
There can only be one /opt as has been discussed when one user wanted to use Entware and Optware components at the same time.

 

[bengalih]

Not going to happen. Entware itself relies on it being mounted to /opt/, this is outside of my control.
There can only be one /opt as has been discussed when one user wanted to use Entware and Optware components at the same time.

I knew this wouldn't be trivial and that if it wasn't Diversion mounting it to /opt then you had no control.
Who is responsible for making this decision as I would like to discuss it with them.
Would it be Merlin or someone who handles the Entware repository?
I can't get over feeling it is bad form and would just like to get an explanation why they mount /opt directly to it instead of accessing it via /opt/entware.

thanks.

 

[thelonelycoder]

I'm mostly concerned due to either Entware and or Diversion (or other scripts) wiping out the entire Entware directory on an uninstall which would also remove anything that might be in "/opt" that doesn't directly belong to Entware.

Diversion gives you the option to uninstall Diversion and Entware (which it likely installed anyway) or only removing Diversion:

Diversion uninstall options

1. Uninstall Diversion and Entware
2. Uninstall Diversion, leaving Entware installed

 

[bengalih]

also, out of curiosity, what do you recommend, or others do when they want to install 3rd party packages that aren't part of Entware. Do you create an /opt at the root of your flash drive to install, install them under Entware, etc?

 

[bengalih]

Diversion gives you the option to uninstall Diversion and Entware (which it likely installed anyway) or only removing Diversion:

Diversion uninstall options

1. Uninstall Diversion and Entware
2. Uninstall Diversion, leaving Entware installed

Right. But one could uninstall Entware believing they are done with it. However, anything else they might have installed to "/opt" I believe would be wiped out too? This is why I feel it is bad convention to claim the whole location.
Again, I realize this isn't your call, just trying to figure out the reasoning.

 

[thelonelycoder]

I knew this wouldn't be trivial and that if it wasn't Diversion mounting it to /opt then you had no control.
Who is responsible for making this decision as I would like to discuss it with them.
Would it be Merlin or someone who handles the Entware repository?
I can't get over feeling it is bad form and would just like to get an explanation why they mount /opt directly to it instead of accessing it via /opt/entware.

thanks.

Your request is unique and far outside from what I want Diversion to do and be capable of. I have no interest to leave the well trodden trail of using the Entware environment as it is now. Discuss it with the Entware team, I have no time for this, sorry.

 

[thelonelycoder]

Right. But one could uninstall Entware believing they are done with it. However, anything else they might have installed to "/opt" I believe would be wiped out too?

Yes and no. When uninstalling Diversion and Entware, I remove the "entware" folder on the device and remove the linking as /opt. Anything outside of the "entware" folder remains untouched by that action.

 

[cmkelley]

Thanks. I have a question/debate to pose which may have been discussed before concerning what would be considered traditional/standardized use of the unix filesystem directory naming structure.

Generally, "/opt" is reserved for optional/3rd party software packages. While Entware of course falls into this category, it is not the sole optional software repository one might install on this device. I feel that claiming the entire "/opt" directory/mount point is a little aggressive.

For instance, if I want to install another application "AppX" to my system, I would generally install this to "/opt/AppX." However this location would now be the link to Entware and "AppX" directory would install alongside the other Entware root directories (e.g. "root", "sbin", "tmp", "etc",...). This would not be ideal.
I could choose to install it to "/opt/opt" which would look a bit better as Entware has no "/opt" within it's structure.

I could choose to put an /opt filestructure at the root of /tmp/mnt/flash_drive and install all my 3rd party products there.
The problem is I can never link this to /opt because Entware has already claimed it.

Ideally, I feel that entware should actually install to "/tmp/mnt/flash_drive/opt" and that /opt should link to this location and all references to Entware should be as "/opt/entware/X".
Or, alternatively, the entire flash drive should just be considered /opt.

I realize that this would likely entail some issues with a new release and upgrades, as well as changes to other scripts.
I don't expect that you will be doing this anytime soon.
However I would like to discuss why this option was chosen and if you believe me to be incorrect in my argument (it's ok to say I'm right and you won't change it...I just need to understand why it was done this way and how you expect/recommend people to deal with this situation).

I'm mostly concerned due to either Entware and or Diversion (or other scripts) wiping out the entire Entware directory on an uninstall which would also remove anything that might be in "/opt" that doesn't directly belong to Entware.

Thoughts?

TL,DR; Entware is WAY bigger than just Merlin's code or even ASUS routers. Changing /opt is never going to happen.

There's a very long history for using /opt in routers the way that Entware uses it stretching back a couple decades to the origins of Optware (I'm gonna go out on a limb here and guess that '/opt' is where Optware got its name), which itself was originally developed for the Unslung Linux project for the Linksys NSLU2 router. Entware, along with Optware, are not just for ASUS routers, they are available across multiple platforms, and advertise themselves as being for embedded devices rather than just routers. Anyone writing software to be used in a router supported by Entware/Optware would be very well aware of the likely existence of Entware or Optware in the /opt directory, and would likely rely on one or the other being there due to the existence of libraries and such in them that don't exist in the base firmware. There are literally thousands of packages complied for Entware or Optware that rely on the existing usage of /opt. Nobody is going to assume that just because you uninstall their software you're going to want to uninstall Entware as well.

I think the use cases where someone would want to uninstall Entware but leave something else in /opt would be a tiny niche; it's difficult to imagine anyone even bothering to uninstall Entware, I don't think it loads anything into memory on a default installation, and apart from a couple small files in /jffs/scripts, exists entirely on an external USB device. Heck, even running the unslung.rc script could be stopped by just commenting the line out of the appropriate script in /jffs.

 

[bengalih]

Your request is unique and far outside from what I want Diversion to do and be capable of. I have no interest to leave the well trodden trail of using the Entware environment as it is now. Discuss it with the Entware team, I have no time for this, sorry.

Not asking for any changes, especially nothing that would conflict with Entware standards - was looking more for clarification/explanation of why. I know you have a good knowledge of the ins and outs working on Diversion and I thought I recalled discussion of this point at some point in the thread, which is why I was asking here.

Just for clarification - you say that you/Diversion is responsible for the mapping entware to /opt (/tmp/opt), but this isn't unique to you? Merlin's installer would do this as well and this is the standard MO for entware on the router?

TL,DR; Entware is WAY bigger than just Merlin's code or even ASUS routers. Changing /opt is never going to happen....
Nobody is going to assume that just because you uninstall their software you're going to want to uninstall Entware as well...
I think the use cases where someone would want to uninstall Entware but leave something else in /opt would be a tiny niche; it's difficult to imagine anyone even bothering to uninstall Entware,

I understand/agree with most everything you mention. Apart from Entware/Optware being decades old...maybe 15 years? The conventions of /opt probably date back to the 70's at latest which is why I'm surprised that Entware seems to be stepping on the toes of those standards to some degree. I would agree that most people probably won't be removing Entware, but disagree that it should have a monopoly on /opt. I could make dozens of comparisons, but it would be like mapping "C:\Program Files" to Microsoft Office only and expecting people to install WinZip or VLC into the Office folder. Like you said, Optware was likely named for /opt, not the other way around.

Yes and no. When uninstalling Diversion and Entware, I remove the "entware" folder on the device and remove the linking as /opt. Anything outside of the "entware" folder remains untouched by that action.

I really don't want to argue the point with you guys as you haven't made the decisions to do it this way (if I am understanding that properly), and appreciate your insight into the matter. I understand you are just working with the existing convention and am not asking for changes from your end. For now I will continue to defend my stance that /opt is not meant to be used for a single software package (or even set of packages in the case of a repo), but will continue to seek some answers.

If I could make a single suggestion you might have some power over it might be that there was perhaps an additional warning that deleting Entware from diversion actually blows away the entire /opt directory. I think most people from a unix admin background would believe that installing something into /opt wouldn't put it at risk should you choose to remove another set of packages (i.e. entware). Of course, if this is how Entware always works on these embedded devices then one should learn the ins-and-out of it, even if it flies in the face of decades unix filesystem standards.

The Entware page you linked me makes it sound like there is no central Entware team to discuss with and seems to link back to the main forums here for questions on Merlin. So, for now I'll take my curiosity elsewhere and if I find out anything interesting I'll chime back in.

Thanks again for the info.

 

[thelonelycoder]

Just for clarification - you say that you/Diversion is responsible for the mapping entware to /opt (/tmp/opt), but this isn't unique to you? Merlin's installer would do this as well and this is the standard MO for entware on the router?

@RMerlin provides the hook /opt in the firmware, and probably more. You'll notice the dead link in a fresh install.
To me when Entware is installed, /opt IS Entware. Never thought of it any other way except for those rare cases where Optware is installed whitch Diversion refuses to install into.

 

[RMerlin]

@RMerlin provides the hook /opt in the firmware, and probably more. You'll notice the dead link in a fresh install.
To me when Entware is installed, /opt IS Entware. Never thought of it any other way except for those rare cases where Optware is installed whitch Diversion refuses to install into.

/opt has been there for historical reasons. AFAIK, it was already used by the original Optware back in the NSLU2 days ("the Slug").

Asus has /opt there because they use it for Download Master (which is based on Optware). I had to modify their implementation for the HND platforms because it conflicted with Broadcom's own use of /opt for debugging scripts that have no reason to be there in a production release anyway.

 

[cmkelley]

Not asking for any changes, especially nothing that would conflict with Entware standards - was looking more for clarification/explanation of why. I know you have a good knowledge of the ins and outs working on Diversion and I thought I recalled discussion of this point at some point in the thread, which is why I was asking here.

Just for clarification - you say that you/Diversion is responsible for the mapping entware to /opt (/tmp/opt), but this isn't unique to you? Merlin's installer would do this as well and this is the standard MO for entware on the router?

Even more general, all routers and embedded devices that use Optware or Entware install it at /opt.

I understand/agree with most everything you mention. Apart from Entware/Optware being decades old...maybe 15 years? The conventions of /opt probably date back to the 70's at latest which is why I'm surprised that Entware seems to be stepping on the toes of those standards to some degree. I would agree that most people probably won't be removing Entware, but disagree that it should have a monopoly on /opt. I could make dozens of comparisons, but it would be like mapping "C:\Program Files" to Microsoft Office only and expecting people to install WinZip or VLC into the Office folder. Like you said, Optware was likely named for /opt, not the other way around.

You say to-may-to, I say to-mah-to. To me, 15 years is within a rounding error of "a couple decades".

Your analogy fails because MSOffice is designed for general purpose computers. Optware/Entware are designed for embedded systems; they are of zero use to anything other an embedded system, they would be completely redundant to the operating system in a general purpose computer. You don't have a Linux system acting as a router, you have a router that happens to use Linux as its firmware - that is a very important distinction. If ASUSWRT were an operating system that could be installed on a general purpose computer (a la pfSense), then you might have a colorable argument.

I really don't want to argue the point with you guys as you haven't made the decisions to do it this way (if I am understanding that properly), and appreciate your insight into the matter. I understand you are just working with the existing convention and am not asking for changes from your end. For now I will continue to defend my stance that /opt is not meant to be used for a single software package (or even set of packages in the case of a repo), but will continue to seek some answers.

You understand correctly, Optware made the decision in 2004.

If I could make a single suggestion you might have some power over it might be that there was perhaps an additional warning that deleting Entware from diversion actually blows away the entire /opt directory. I think most people from a unix admin background would believe that installing something into /opt wouldn't put it at risk should you choose to remove another set of packages (i.e. entware). Of course, if this is how Entware always works on these embedded devices then one should learn the ins-and-out of it, even if it flies in the face of decades unix filesystem standards.

This is in fact how Optware and Entware work, and always have since 2004 as noted above.

Note that not all Unix systems even use /opt, none of the *BSDs do, they use /usr/local, and BSD predates even the original filesystem standard by almost 20 years (BSD=1977, FreeBSD=1993, filesystem hierarchy standard=1994). Do all Linux distributions actually use /opt? Do even all of the major ones? It's an honest question, I've dabbled with Linux but I never got that involved with them; I've used FreeBSD since around 2004. On a standalone computer system, I struggle to see a use difference between /usr/local and /opt, I wonder if /opt was originally intended for applications that resided on a network share rather than on the local machine?

The Entware page you linked me makes it sound like there is no central Entware team to discuss with and seems to link back to the main forums here for questions on Merlin. So, for now I'll take my curiosity elsewhere and if I find out anything interesting I'll chime back in.

Thanks again for the info.