In a JBoss Vault expression, what is the meaning of the last (numerical) segment?
VAULT::vaultBlock::attributeName::1
And what is it for?
The last segment of a JBoss Vault expression was used to put the shared key, but it is no longer needed. By default vault.bat puts 1.
See https://issues.jboss.org/browse/WFLY-4238?focusedCommentId=13031690&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13031690
Related
EDIT: Turns out the mystery string was a simple MD5 hash of the name of the file (including the extension and capitalization).
I'm attempting to automate the process of creating a Chained MSI through InstallShield. In the GUI, this involves going to Releases, adding a chained package, linking to the MSI and streaming the file into the project.
I've reverse engineered what exactly happens behind the scenes by analyzing the project file as XML. It essentially just comes down to table edits. I understand you can use Windows Installer Automation to open an *.ism file and access the database tables (LINK).
Yet, there is a single field in the ISChainPackageData table which I cannot seem to generate or figure out how it was calculated. It is the column titled, File. It is a 32 character hex string preceded by an underscore. I have discovered that the only attribute that determines this field is the name of the MSI file being streamed. For example:
Linking to a chained MSI by the name of Test.msi, yields _29B31F67F21C9EE77CBF8C4C5D24ACE9.
Changing the name would change this. Changing the file, including replacing it with an empty file of the same name, does not.
I believe it is some kind of simple hash of the name, but I haven't had any luck guessing it.
Does anyone have any insight on what they might be using here?
Thanks!
Close. It's a hash-based GUID of a combination of a few things. I'd have to trudge up the code to find out exactly what, but it's at least the relative path and filename, and possibly something related to the package in question (probably its primary key value).
This is used to generate a unique key for each file you include with a package, without allowing duplicate files. (Windows Installer doesn't like backslashes in its primary keys.) The actual value here isn't meaningful; if you're careful to avoid duplicate keys and don't overlap file path and name combinations, you can probably put in any valid key value you like. However that may prevent the IDE from detecting duplicates itself.
I'm having trouble correctly using the /GROUP="" command line parameter for my installation when called by a parent installation. What exactly should be specified and what is the "base"?
For example, the parent installer determines the full path to where the start menu entries will be. If this path is passed to /GROUP, it gives an error about invalid characters; namely, :.
I know the parameter supports use of expand prefix, but does this mean the parent installer must determine which constant to "expand" rather than simply passing the already determined path?
UPDATE:
It seems I was mistaken in thinking I could select the "base" of the menu entries (all users, local). It seems this is done automatically, but perhaps this is a more complete example:
An older Wise installation determines the filesystem path where the menu entries will be installed. It then executes my installation and passes that path using /GROUP. This is where my problem arises because /GROUP expects only a directory, not a full path.
The /GROUP="x" parameter specifies the value for the {groupname} constant, eg. it should be of the form /GROUP="MyApp". It should not contain a path, or at least if it does contain one it should be a very shallow relative path such as /GROUP="MyCompany\MyApp".
If you are passing the parameter from a parent Inno install script and you want the child install to install icons into the same group as the parent then you should use /GROUP="{groupname}".
In all cases, the "root" of the path will automatically be chosen by Inno to be either {commonprograms} or {userprograms} depending on the PrivilegesRequired setting of the install script being run.
Note that if you are running the installer as part of an automatic update to an already-installed application, you should not pass the parameter at all. Inno will remember the user's previous selection and use this by default; in fact it's strongly recommended to not offer the user a chance to change this during interactive upgrades by setting the following:
[Setup]
DisableDirPage=auto
DisableProgramGroupPage=auto
In view of my previous question Script for recursive add-to-source control: How to ignore specific files and folders, an issue that arose in regard to the command clearprompt (whereby to generate a list of elements for source control) is that it has restrictions on the number of elements it can process. So my question is: Is there a way to allow for a larger number of elements?
clearprompt has some limitation, in term of size, number of character per lines, and as you see, number of elements.
Those aren't fixed, on Windows or Unix, as far as I know.
So it is best to split your list, and to display several clearprompt dialogs, with a header specifying the number of said dialog over the total of number of windows expected (1/6, 2/6, 3/6, ...)
The only other solution would be to rely on another library to dispolay that dialog, but the advantage of using ccperl is that it is installed with the ClearCase client, which means it is available on all client workstation.
I believe I encounter a similar issue where because of this limit, the clearprompt dialog was empty. I debugged the script and the error seems to be because of the system limit of the max command line which was passed to echo in the following statement
`echo $listelement > $list_add`
I just changed this line to the following
open(LIST_ADD,">".$list_add);
print LIST_ADD $listelement;
close(LIST_ADD);
or basically, instead of relying on the shell to copy the content, I am doing the same through perl and that resolved the issue.
how can we identify notepad files which is created in two computer, is there a any way to get any information about in which computer it was created.Or whether it is build in xp or linux.
If you right click on the file, you should be able to see the permissions and attributes of the file.
Check at the end of the line. Under GNU/Linux lines end with \n (ascii: 0x0A) while under Miscrosoft W$ndos it is \r\n (ascii: 0x0D 0x0A).
Wikipedia: https://en.wikipedia.org/wiki/Newline
found this: http://bit.ly/J258Mr
for identifying a word document but some of the info is relevant
To see on which computer the document had been created, open the Word
document in a hex editor and look for "PID_GUID". This is followed by
a globally unique identifier that, depending upon the version of Word
used, may contain the MAC address of the system on which the file was
created.
Checking the user properties (as already mentioned) is a good way to
see who the creator of the original file was...so, if the document was
not created from scratch and was instead originally created on another
system, then the user information will be for the original file.
Another way to locate the "culprit" in this case is to parse the
contents of the NTUSER.DAT files for each user on each computer. While
this sounds like a lot of work, it really isn't...b/c you're only
looking for a couple of pieces of information. Specifically, you're
interested in the MRU keys for the version of Word being used, as well
as perhaps the RecentDocs keys."
The one thing I can think on the top of my mind is inspecting the newline characters on your file - I'm assuming your files do have multiple lines. If the file was generated using Windows then a newline would be characterized by the combination of carriage return and line feed characters (CR+LF) whereas a simple line feed (LF) would be a hint that the file was generated in a Linux machine.
Right click one the file--> Details . You can see the computer name where it was created and the date.
I'm in the planning stages of a script/app that I'm going to need to write soon. In short, I'm going to have a configuration file that stores multiple key value pairs for a system configuration. Various applications will talk to this file including python/shell/rc scripts.
One example case would be that when the system boots, it pulls the static IP to assign to itself from that file. This means it would be nice to quickly grab a key/value from this file in a shell/rc script (ifconfig `evalconffile main_interface` `evalconffile primary_ip` up), where evalconffile is the script that fetches the value when provided with a key.
I'm looking for suggestions on the best way to approach this. I've tossed around the idea of using a plain text file and perl to retrieve the value. I've also tossed around the idea of using YAML for the configuration file since there may end up being a use case where we need multiple values for a key and general expansion. I know YAML would make it accessible from python and perl, but I'm not sure what the best way to access it from a quickly access it from a shell/rc script would be.
Am I headed in the right direction?
One approach would be to simply do the YAML as you wanted, and then when a shell/RC wants a key/value pair, they would call a small Perl script (the evalconffile in your example) that would parse YAML on the shell script's behalf and print out the value(s)
SQLite will give you greatest flexibility, since you don't seem to know the scope of what will be stored in there. It appears there's support for it in all scripting languages you mentioned.