As custom action of a WiX-based installer (MS Windows 7), I need to check out some files from a StarTeam server. stcmd seems to provide all functionality and I am able to perform the checkout with UID and password provided via parameter -p.
Since the installer is run by different users, I obviously need a mechanism to inquire the StarTeam login credentials at run-time instead of hard-coding UID/pw.
I was browsing the StarTeam manual but was not able to figure out if the StarTeam programs provide a solution to that problem. Any suggestions?
Sorry, this just doesn't make sense to me. Typically you include files from source control in the MSI at build time not install time. What does install time buy you other then complexity? Now application runtime would make sense to me. You could create and install an application that prompts the user for creds and then periodically polls star team for updated files. (Windows service, scheduled task, logon autorun...)
Couldn't you could prompt your users for the login information during the install and then pass them to the stcmd.exe?
Meh, the solution is trivial. When using an empty password, stcmd automatically asks for the password. Example:
stcmd connect username:#hostname:portnumber
Using the stateful commands is recommended since the credentials are stored internally for all subsequent commands.
Related
I got a MSI setup with personilized UI and Custom Actions working properly. It will be deployed on a specific park of computer, with always the same account design:
An Operator account with classic privilege.
A Setup account with administrator privilege.
We want to be able to launch our MSI on both account, but when doing it from the Operator, have to fill a form asking for the Setup credentials and install everything as it was made logged with the setup user.
Is there a Windows/MSI tool for that?
Can I do it with a specific Custom Action launched before the display of the UI?
Thank for your help
When you deploy an MSI to a user that has standard privileges this will always ask you for Admin credentials to install the MSI (assuming the MSI is a per-machine install and not a per-user install).
If you deploy your software via SCCM or other infrastructure management tool you can place this to run in an Administrator Context, thus, you won't need the Administrator privileges in order to install it.
Also, when you test an MSI it's nice to test it with PSexec. What is Psexec? Check it here.
PsExec is a portable tool from Microsoft that lets you run processes remotely using any user's credentials. If you run psexec -s -i (in a cmd with administrator rights) this will impersonate the System account and thus allow you to install applications without requiring you to provide administrative right (password, etc).
PSexec is a must when you test MSI's. For example, if you have any user data in your MSI. Because, when you install an MSI from another account, not all the data is automatically placed on the other user, for this you have to use ActiveSetup or other solutions to make it available on all users. See more about userdata here and any other MSI topics.
If you are installing an MSI from an Administrator account and want to run different actions on the current logged in user, i designed a tool for this that can be downloaded here.
So, to answer your question more directly, you can't suppress the credentials dialog as a normal user. The MSI must be deployed from some infrastructure management tool like SCCM, or another solution (which i don't recommend) is to design the MSI to be a per-user installation.
We would like to change the password for our TFSService account. This is the domain account that was used install TFS and has several Windows services running under it.
I did review the link below on changing the TFS service password. Is it as simple as updating the password in Active Directory and then using the TFS administration console to update the account password? Are both steps above required? Are there any additional tasks required?
https://learn.microsoft.com/en-us/tfs/server/admin/change-service-account-password
thanks
Yes, it should just be that.
As with any production environment, there may things in your setup strangers on the internet are not aware of, so it would be best to test this process on a non-production copy if possible first.
Although I know setting up a non-production copy of TFS will end up probably end up running on a different domain.
I am learning puppet and am trying to write modules to install services such as tigervnc and openvpn.
The problem is that for tigervnc requires the initial password setting by the user. I have tried using:
"exec {'/usr/bin/echo password | /usr/bin/vncpasswd > ~/.vnc/passwd"
This works if I run it on the command line if I'm logged in as the user but does not work when run via puppet.
The problem with openvnc is that it requires a lot of user interaction for the default settings for certificate generation/certificate authority and key generation.
I have tried using execs with the "pkitool" methods which work to a point but not very well or stable. I am also wary of using many execs if there is a better way to do it.
So to sum up my main question is how to deal with these user interactions when trying to automate installations with puppet, and is there a better way than running lots of execs which to me seem like a last resort ?
Thanks
If setting up a piece of software requires user interaction, I don't really see a way around exec. Keeping its use to a minimum is indeed a sensible design goal.
An economic approach is to
create a script that does all the necessary lifting that Puppet resources cannot perform
make Puppet deploy that script to the agent
run it at appropriate times via exec (along with good creates or onlyif queries)
Scripts that run installation wizards that rely on interactive input should probably rely on expect and friends.
I am moving a copy from server a to server b and server b is asking for the DNN version to be upgraded. The problem is we do not have the host password. I tried to upload a password recovery file via FTP and we cannot see it since everything keeps redirecting to this upgrade. Is there a way to stop the upgrade redirect so we can get the host password and then re-enable it??
Upgrade
Current Version - 06.02.08
Upgrade - Version 07.02.01
You are about to upgrade your website to a more recent version of the application. Applying upgrades on a consistent basis is the best way to ensure that you are protecting the integrity of your investment and the security of your users and assets. Before proceeding with the automated upgrade process please ensure that:
You can have the upgrade fire off without typing in a password, just go to /install/install.aspx?mode=upgrade and it should run the upgrade without needing to login as HOST. then you can recover the password afterwards.
I've never seen a server which ask for a DNN upgrade. The upgrade process will run only if you've update files with an upgrade package.
Moreover, the 2 versions mentionned are the assembly version and the database version. Moving DNN from a server to another server doesn't modify none of them. Did you copied the database too? I suspect that your dnn copy is connected to another database which is in DNN 6.2.8. It could explain why dnn is attempting to upgrade it.
Regarding the recovery of the host password, I don't know how to proceed. Haven't you a superuser account on this dnn instance?
Open your web.config and make sure AutoUpgrade is set to False.
For the password issue, do you have the password for any other users?
If so, I believe you can go into the AspNetUsers table and copy the PasswordHash/Salt of that user to the PasswordHash/Salt of the admin user. Then, you should be able to login with the Admin username and the other user's password.
Note: Please make sure you have a database backup before trying this.
In Visual Studio 2012, using publish profiles along with web deploy simplifies the deployments quite a bit. However it still is missing few things or may be I don't know how to use it yet.
I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can this be done? If I leave the username and password empty, I am prompted for it. Is there a way like manually modifying the .pubxml files?
Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in PublishProfileName.pubxml.user that is local to each user? I could at least save the username but obviously don't want that to be checked in.
The Configuration itself is not part of PublishProfileName.pubxml but is stored in PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
Same for the Platform as last point.
I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.
EDIT
The command line that works fine for publishing is
MSBuild.Exe MyProject.sln /p:Configuration=QA /p:DeployOnBuild=true;PublishProfile=PublishToQA;AllowUntrustedCertificate=true /p:authType=NTLM /p:UserName=
In this I would like to omit the /p:Configuration=QA if the configuration becomes part of the publish profile itself.
Some answers to your questions.
I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can
this be done? If I leave the username and password empty, I am
prompted for it. Is there a way like manually modifying the .pubxml
files?
Your authentication is typically driven by how Web Deploy is hosted. By default if you are using the Web Management Service then you are using IIS users for auth. With IIS users you can control which users have permissions to specific sites/apps. You can configure WMSVC to use windows auth as well though. If you have issues using VS for those scenarios let me know.
If you are using the Remote Agent service to host Web Deploy then in this case you'll be using windows auth.
Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in
PublishProfileName.pubxml.user that is local to each user? I could
at least save the username but obviously don't want that to be checked
in.
We have another mechanism for you to determine what information is private/shared. With the exception of the password all publish info is shared (and checked in by default). In order to simplify the design you can either have a publish profile which is shared, or one which is not shared at all. There is no in-between in which you have a profile that some fields are shared and other not. Password is special cased here and encrypted on a per-user/per-machine basis in the .pubxml.user file.
If you'd like to have a private publish profile then you can simply not check in the .pubxml file which corresponds to the publish profile. These are stored in the Properties\PublishProfiles (or My Project\PublishProfiles for VB) and just exclude them from the project and don't check the files in. The publish dialog looks for the profiles on disk, not just the ones which are in the project. Everything should continue to work.
We don't support the concept of selectively storing values in the .pubxml.user file. The publish dialog will only store a set number of values in that file. Instead of
The Configuration itself is not part of PublishProfileName.pubxml but is stored in
PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
Same for the Platform as last point.
This was a mistake it should have been stored in the .pubxml file, not the .pubxml.user file. We have since fixed this, but haven't had a chance to release the update yet.
The Configuration property cannot be set in the publish profile. The Configuration property is a core part of the build process. To be more specific, the reason why we didn't call this property Configuration is because the .pubxml file is imported into the definition of the .csproj/.vbproj during a build & publish. Since other properties are defined based on Configuration you cannot change the value once it's been set. I just blogged with way too much detail on this subject at http://sedodream.com/2012/10/27/MSBuildHowToSetTheConfigurationProperty.aspx. This limitation is an MSBuild thing not a publish limitation. For command line you should specify Configuration in the following way:
msbuild.exe myproj.csproj /p:...(other properties)... /p:Configuration=
I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.
We don't have direct support for this, but if you expand on your needs I may be able to help. FYI I have an extension which you may be interested in. I have posted a 5 min video to http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx.
You are free (and encouraged) to manually edit your pubxml files, so feel free to remove the password.
To switch to NTLM, change AuthType to NTLM in the first PropertyGroup.
Platform and Configuration remain build configuration, the user file just stores them so Visual Studio knows what the last configuration you deployed was.
By multi-server, do you mean a web farm? If so, you might try looking at the Web Farm Framework which basically performs MSDeploy syncs from the primary server to the others.
Alternatively, you could switch to the command line and use postSync to upload and execute a batch file on the remote server that triggers the other deployments from there.