ODB /Custom is broken
ODB "/Custom /VMEPS" is set to "/home/agdaq/online/src/vmeps.html", clicking on the "VMEPS" button on the left-hand-side menu yield error: Cannot open file "/home/agmini/packages/midas//home/agdaq/online/src/vmeps.html", errno 2 (No such file or directory) This used to work. K.O.
Comments (7)
-
reporter -
My custom pages do not work with /Custom/Path set to ""(blank) because having the "Path" key present causes the resource files to be handled differently, i.e. look for resource files under the directory given by "Path" key rather than use the /Custom/xxx entries. This difference is documented. Can this be fixed so it works as before if "Path" is set blank or must we now use "Path" and fix all the old pages? In this case the documentation needs to be changed. SD
-
reporter Yes, I think I will undo the recent changes and make it work last it used to. At the list it will stop serving the /etc/passwd file.
Suzannah, can you point me to the documentation page that describes this?
K.O.
-
The documentation about Path behavior is here:
https://midas.triumf.ca/MidasWiki/index.php//Custom_ODB_tree#Path_key
-
reporter Thanks. K.O.
-
reporter original problem is fixed: a) default value of /Custom/Path is blank. b) blank /Custom/Path is not appended to the path. c) blank /Custom/Path does not change how custom files are served. K.O.
-
reporter - changed status to resolved
fixed as of tag midas-2019-03-b
- Log in to comment
Ok, I found the problem. Unexpectedly, there is an ODB entry "/Custom/Path" set to some value of $MIDASSYS. In the past, mhttpd did not create /Custom/Path if it did not exist, but now I see code that creates it unconditionally. This definitely breaks the common use of /Custom where /Custom/xxx entries were always permitted to contain the full path of the file to serve, it was not mutated or prepended with magic prefixes. A fix is to set /Custom/Path to "" (blank). My /Custom web links work again. K.O.