I have a question regarding the following warning when using
Ezjail-3.4.1 on FreeBSD 10.2
/etc/rc.d/jail: WARNING: Per-jail configuration via jail_* var "enter code here" iables is obsolete. Please consider to migrate to /etc/jail.conf "enter code here"It is my understanding that this has changed in FreeBSD 9.0 but since 10.2 the new way is the default method and that warning is being generated.I haven't been able to find any information about this on google, a lot of users mentioning the errors but ignoring them because their jails still work.AFAIK in 10.0 the rc.d/jail script converts the old-style jail_
variables into a temporary jail.conf to handle the jail. So the warning
is generated by rc.d/jail
Regards
Mr-Hill
As you found out, jails on FreeBSD 10.x use a new configuration method. From /usr/src/UPDATING:
20131010:
The rc.d/jail script has been updated to support jail(8)
configuration file. The "jail_<jname>_*" rc.conf(5) variables
for per-jail configuration are automatically converted to
/var/run/jail.<jname>.conf before the jail(8) utility is invoked.
This is transparently backward compatible. See below about some
incompatibilities and rc.conf(5) manual page for more details.
These variables are now deprecated in favor of jail(8) configuration
file. One can use "rc.d/jail config <jname>" command to generate
a jail(8) configuration file in /var/run/jail.<jname>.conf without
running the jail(8) utility. The default pathname of the
configuration file is /etc/jail.conf and can be specified by
using $jail_conf or $jail_<jname>_conf variables.
Please note that jail_devfs_ruleset accepts an integer at
this moment. Please consider to rewrite the ruleset name
with an integer.
ezjail was never updated to use this new method, but that's ok: FreeBSD still accepts the previous method. You can ignore this warning.
Related
I note that when cygwin's setup.exe installs packages now, it looks for a file named "setup.zst.sig" first. What's the content and format of this binary file? How to produce a valid "setup.zst.sig"?
This must have been a recent change. Previously it looked for "setup.exe.sig" first. I use the feature (to detect whether "setup.exe.sig" changed) to decide whether my cygwin installation needs to be updated. See also this for an application example.
EDIT: #matzeri:
setup.zst.sig is not yet used.
The "zst" functionality was introduced in the program to eventually replace the
previous compression methods of setup.ini and the packages
const std::string setup_exts[] = { "zst", "xz", "bz2", "ini" };
For checking the update of setup-ARCH.exe you need to use the standard signature.
https://cygwin.com/setup-x86.exe.sig
https://cygwin.com/setup-x86_64.exe.sig
The pop up you shows seems to happen only on FTP mirror server, the HTTP servers
do not produce it.
It is clearly a bug in setup
https://cygwin.com/ml/cygwin/2019-02/msg00153.html
According to the documentation, the .sig files carry a SHA-512 hash of the respective file without that extension, signed with the private key available only to Cygwin the company.
https://www.cygwin.com/faq.html#faq.setup.install-security
After i have made some libraries load directly when i open Dymola by modifying the file : "c:/program files (x86)/dymola 2016 fd01/insert/dymola.mos" , and adding those lines :
Utilities.setenv("MODELICAPATH","C:/Users/hrameh/Desktop/EnergySystems_V2-73p/ModelicaLibraries/ExternalMedia-master/Modelica/ExternalMedia 3.2.1");
openModel("C:\Users\hrameh\Desktop\EnergySystems_V2-73p\ModelicaLibraries\ExternalMedia-master\Modelica\ExternalMedia 3.2.1\package.mo");
Utilities.setenv("MODELICAPATH","C:\Users\hrameh\Desktop\EnergySystems_V2-73p\ModelicaLibraries\EnergySystems");
openModel("C:\Users\hrameh\Desktop\EnergySystems_V2-73p\ModelicaLibraries\EnergySystems\package.mo");
Utilities.setenv("MODELICAPATH","\illuin\users$\hrameh\Mes documents\Dymola");
The model works completely fine in Dymola. But, when trying to simulate the model via Python using the buildingspy library, the simulation fails. Any suggestions to help me find a solution?
I guess your problem is, that buildingspy relies on the default working directory path Dymola gets when the dymola.exe is called by buildingspy - but the openModel-commands in your dymola.mos change the working directory.
Use
openModel("<path-to-package.mo>", changeDirectory=false);
to avoid this.
Additionally, with newer Dymola versions, you must ensure that no saved startup directory is used, by selecting: Edit -> Options -> Settings -> Do not save Startup directory.
As you currently use Dymola 2016 FD01 this is not a problem for you at the moment.
Such problems can be detected by showing the Dymola window when buildingspy simulates a model. You can do this with showGUI as shown in this minimum example:
import os
from buildingspy.simulate.Simulator import Simulator
os.environ["PATH"] += os.pathsep + "C:/Program Files (x86)/Dymola 2016 FD01/bin"
s = Simulator("Modelica.Blocks.Examples.PID_Controller", "dymola")
s.showGUI(show=True)
s.simulate()
Some further hints for your example:
You do not need the Utilities.setenv()-calls to open a library. openModel is sufficient
I would not use Utilities.setenv, as this is an undocumented and apparently a very old package (creation date is from 2004). Use Modelica.Utilities.System.setEnvironmentVariable instead. This way you also don't get an extra package loaded in the package browser
Using the file /insert/dymola.mos has some disadvantages:
it is used system wide by every user, so it should not contain paths to user directories
if you install a new dymola version, you must edit the insert/dymola.mos file of this installation again
Alternatives to dymola.mos
In Dymola 2016 FD01 use the file setup.mos instead to add the openModel commands (located in C:\Users\\AppData\Roaming\Dynasim)
Newer Dymola versions don't have setup.mos anymore, but setup.dymx for the settings and startup.mos for the user commands (to open libraries, etc.)
For a scenario, I am using Jmeter with WebDriver Sampler. So for uploading a file, since I need to run in Jenkins, I have to pass the absolute path of file. To get the current path I defined following command in User Defined variable.
${__groovy(import org.apache.jmeter.services.FileServer; FileServer.getFileServer().getBaseDir();)}${__groovy(File.separator)}
When I log this its working fine. Its showing the file path correctly. But when I use this in WDS and try to log. I am getting the file path with all the backslash removed and unnecessary spaces.
C:\ram\file\part1\renamed.txt
It has to be printed like this, but instead
cramfilepartrename d
It prints like this. Any idea what can be the issue ?
I cannot reproduce your problem using latest versions of JMeter and WebDriver Sampler:
Make sure to upgrade to JMeter 4.0 (or whatever is the latest version available at downloads page)
Make sure to upgrade WebDriver Sampler plugin to version 2.3 using JMeter Plugins Manager
Make sure to use WDS.log shorthand to print the variable value
I am required to make a custom FireFox profile on a RHEL based system.
most of the configuration are changed inside the FireFox inside the about:config menu.
When I try and lock parameter values using the "mozilla.cfg" file and the "lockPref("", )" function the browser doesn't seem to read those files, I place the file both in: "~/.mozilla/firefox/" and "/usr/lib64/firefox/". I used the http://kb.mozillazine.org/Lock_Prefs guide and some more and still I have no one answer about where those function should be written and how do I check that those functions were loaded.
I would like some clear instructions or a definitive guide that I just couldn't manage to find.
Thanks!
This came up fairly high in a Google search when I was asking the same question, but did not have an answer at the time.
I found the following reference:
https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment
On RHEL7, the files needed to be added to the following locations:
/usr/lib64/firefox/defaults/preferences/autoconfig.js (root:root, 644)
/usr/lib64/firefox/mozilla.cfg (root:root, 644)
With MSTest.exe, you can specify a total timeout for a test run by setting the /TestSettings/Execution/Timeouts/#runTimeout attribute in a .testsettings file.
With VSTest.Console.exe, the .testsettings has been deprecated in favor of .runsettings, which apparently has a completely different schema (with, ahem, sparse documentation). I know that I can configure the .runsettings file to use legacy MSTest mode (thereby allowing me to use a .testsettings file), but I would prefer to avoid that if possible.
Is there a way to set a run timeout in the .runsettings file? Or is there a different way to get the same effect?
Yes, there is. Please see RFC here: 0011-Test-Session-Timeout.md