Is this command required to enable saml in Liberty server?
bin/installUtility install samlWeb-2.0
I have configured <feature>samlWeb-2.0</feature> in my server.xml and able to get metadata file using the url https://ip:port/ibm/saml20/defaultSP/samlmetadata
It's <feature>samlWeb-2.0</feature> that enables the feature, but you can't enable what you don't have, which is where bin/installUtility would come in (if necessary).
Liberty is available in several packages which dictate which set/sub-set of features are available immediately after installation (custom packages of Liberty can also be created to further customize the available set of features available to the runtime). Features that are not included in the package can be installed afterwards using bin/installUtility (bin/featureManager has been deprecated).
The command bin/installUtility install samlWeb-2.0 retrieves (from a repo) and installs the samlWeb-2.0 feature if it wasn't already installed in your Liberty runtime. For example, if the Liberty package was that of just the Liberty Kernel, than bin/installUtility install samlWeb-2.0 would download the samlWeb-2.0 feature along with all other pre-req features. However, if your Liberty package was that of the entire Base edition (wlp-base-all) than it would already include the samlWeb-2.0 feature and you would not need to run bin/installUtility prior to enabling it.
Related
I am trying to install DB2 ibm data server client(version 11.1), silent install in my windows server. i am using response file for the installation. I gave the path in response file to install in D drive, but still it is installing in C drive only. the command i was using is: msiexec /i "MSI path" /q /l*v "log file path" RSP_FILE_PATH="response file path".
Check the following:
Installing Db2 products and features using a response
Some notes on MSI customization in general below.
And a link to the most commonly used library of packaging tips contributed by packagers:
https://www.itninja.com/software-library/company/ibm
Different Designs: The exact mechanism used to redirect a folder like that depends on the design of the application and the setup from the vendor, they often do something very non-standard so reverse engineering their solution fully or slightly is usually neccessary.
Itninja.com: Maybe have a look if you can find the software here in the itninja.com "software tips" section: https://www.itninja.com/software-library/company/ibm - this is a collection of comments people have made who have packaged and deployed the software in question - either unsuccessfully or successfully. I can't really tell what the exact product name is, please check.
Download: If you have a download link that is publicly accessible I can have a quick look at the MSI to determine how it is set up. Please be aware that it is much better to install an MSI directly via normal configuration mechanisms (setting public properties and / or creating a transform - sample here) than to run a setup.exe with response file (which sometimes is the only possibility depending on the overall deployment design).
How to make better use of MSI files
A couple of quick overviews:
How to parameterize msi file from electron builder
MSI Repackaging - free tool
And some further links for reference:
Change the value of a MSI property loaded from a DLL using a MSI transform
How to run an installation in /silent mode with adjusted settings
I want to set up a workflow that allows me to have a git repository with a uniform/consistent formatting. The developers (approx. 30) should be able to commit properly formatted changes to their local repository easily, independent of their operating system (either some Linux or Windows 10) and independent from their IDE. Changes shall be pushed to a Linux server which administrates the remote repository.
From my point of view there are two steps necessary to ensure that the remote repository is properly formatted:
Format the current state of repository according to a set of rules.
Format the files affected by every new commit according to these rules.
The first step can be implemented easily by running an auto-formatting tool (e.g. clang-format) on the complete repository. The implementation of the second step can be further divided into two substeps:
2a) Client side: Format a commit properly before pushing it to the server.
2b) Server side: Check if the repository will be properly formatted after the changes of the commit are applied.
The second substep (2b) can be implemented easily (simlar to step 1). However, the implementation of the first substep (2a) is more demanding and I would like to reach out to the community for tipps/tricks/ideas.
So far I've had a closer look on the Eclipse autoformatter and clang-format:
The Eclipse autoformatter can only be used when Eclipse is installed, I haven't found a Eclipse autoformatter standalone application. Is it possible to run the eclipse autoformatter from the command line without a GUI?
clang-format is a unix tool which I cannot install and run standalone on a windows system. I've seen there is a LLVM executable for windows but I am not sure if the installation will inflict any undesired changes to my system. Is anybody using LLVM/clang-format on windows?
Are there other auto-formatting tools for C which work on Linux and Windows 10? Is anybody successfully using python scripts for this purpose?
I would like to override the default powershell scripts that come with win_chocolatey module of Ansible. How do I do that?
In my case, I am trying to override the ChocolateyInstall.ps1 that comes with MsSqlServerManagementStudio2014Express. I would like to pass a few more parameters such as system administrator password and instance names during the silent installation of MsSQLServer.
I have tried giving these additional parameters with "install_args" and "params" options in win_chocolatey module call in my ansible playbook. But there are no handlers written in MsSqlServerManagementStudio2014Express's powershell scripts to include them during silent installation.
Package Parameters vs Install Arguments
Install Arguments (--install-arguments option for choco.exe) are completely invisible to the packaging, and they are appended to the current set of silent arguments in the package. One can also override them completely with --override-arguments. In the commercial editions of Chocolatey, you can also pass --install-arguments-sensitive to keep secrets out of logs.
Package Parameters (--package-parameters|--params) are different, can be used with anything related to packaging (not just for the installer), but must also be present in the packaging itself. For commercial editions and secrets, you also have --package-parameters-sensitive.
Option 1: Community Repository Packages
You would need to ensure that the package is using Install-ChocolateyPackage, Install-ChocolateyInstallPackage, or other built-in methods to know that install arguments can be used with the package. If you need parameters, you will need to work with the maintainers of the package to get those implemented.
Option 2: Use Your Own Packages
If you are using Chocolatey in an organization, you will want to use your own package you store somewhere internally. That guarantees much more reliability and repeatability, something that is instrumental to organizational use of anything.
Plus you can bake installers directly into the package as you are not subject to distribution rights internally, providing an even more reliable experience.
It is especially helpful to read over and understand this when planning for Chocolatey in an organization: https://chocolatey.org/docs/community-packages-disclaimer
IBM offer an installable MQSeries Client software that allows you to access queue managers on remote hosts. They also offer some C-callable libraries that let you do messaging from a C application.
My problem is that I don't have admin access on the hosts I plan to test-deploy on, and getting an application installed comes with bigtime Enterprise hassle. IBM, meanwhile, acts as if there's no alternative to installing their whole client package. Assuming I'm willing to forgo their support, can I get around this? i.e. is there some set of objects/libraries I can link with to produce a standalone client?
From v8.0.0.4 onwards, IBM provides set of libraries as a zip/tar and you don't need to install whole client package. See here: http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.ins.doc/q122882_.htm.
But you still need queue manager running somewhere to test your application.
For Linux packages, specifically RPMs with stored checksums, we always can check two things: the contents of package is ok and the installation from this package is ok. When someone modifies parts of the installation he shouldn't, we can see it by running rpm -Vp my-precious-package. In our busyness it is not only recommended, but obligatory to provide our packages with tools for this purpose and for Linux these are just simple bash scripts.
Now I have to do something similar for Windows. Basically what I want is to provide some batch file by running which one can get assured, the installation is the same as it meant to be in the package. I'm using InstallShield for packaging, and yet it has some great visual tools, I still haven't found a way to verify package checksums in the command line.
Is it even possible, or should I reinvent the wheel writing my own checking utils?
Take a look at MakeCat and SignTool from Microsoft, both in SDK
http://msdn.microsoft.com/en-us/library/windows/desktop/aa386967%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa387764%28v=vs.85%29.aspx
Windows Installer has a feature called resiliency that supports auto repair of products and there are ways to call it for self checks only. (This is assuming by InstallShield you mean Windows Installer based projects.)
Here's a couple links to read to get you started:
INFO: Description of Resiliency in Windows Installer
Resiliency
Application Resiliency: Unlock the Hidden Features of Windows Installer
MsiProvideComponent function (See dwInstallMode flags)
This also assumes all files are key files. Companion files are not managed by the installer. Also changes performed by custom actions outside of the installer aren't managed.