Closed bodyakov closed 8 years ago
@bodyakov Neither of these logs have all of the output. We need all of the output (the configuration information is super important) to help us understand what may be wrong. Without that information, there isn't much we can help with.
At one time puppet update many packages. Log will be very big.
I see the issue. On the systems it is failing on, it's when it is already installed.
Maybe....still investigating.
it can't be installed because: DEBUG: Running 'Start-ChocolateyProcessAsAdmin' with exeToRun:'msiexec', 2016-04-01 07:51:01,805 [INFO ] - statements: '/x{F17FBC84-B1B8-4816-B0A2-24F86C20E8E6} /q REBOOT=ReallySuppress'
And problem that program actually was unistalled after chocolatey update. We have a lot tickets from users to HelpDesk.
This problem occur not only on our internal packages. There are many cases (about 3%) when other programs are not installed. Such as flashplayerplugin, adobereader, etc
FYI - don't do this https://gist.github.com/bodyakov/0896babe7ad213e078ba6cf80aee2fb3#file-ok_long-L120. It's really bad what it does to your system - https://github.com/chocolatey/package-validator/wiki/DontUseGetWmiObjectForFindingInstalledPackages
If you are using this as an organization, please ensure you are not using the Community Feed (https://chocolatey.org/packages). Please see https://puppetlabs.com/blog/chocolatey-hosting-your-own-server for the reasoning.
If you are downloading packages from the community feed to use internally, ensure you are recompiling the packages for internal use. See https://docs.puppetlabs.com/pe/latest/windows_modules.html#copy-an-existing-package-and-make-it-internal-repackaging-packages
Accepted. In some packages i rewrite this on regisrty, accepted. in many packages I rewrote it through the registry, but there is still left.
From what I can tell, right now it appears it is a logic error in your automation scripts. I'm not sure Version is guaranteed coming from what you are calling. Instead if you must remove old versions as you are doing, I would do the search based on the product code.
https://gist.github.com/bodyakov/0896babe7ad213e078ba6cf80aee2fb3#file-ok_long-L135-L145
Your package is installing two things. Not usually recommended.
So crazy question - why can't your MSI handle upgrading properly?
If it's _all internal_ and you can't get MSIs working with upgrades and downgrades, my recommendation may be to stop using MSIs and just package the binaries right into the package. Again, if it is all internal.
I know that most commercials MSIs I deal with can handle the upgrading just fine, so you don't need to attempt to remove older versions.
In 0.9.9.x - if anything writes to the stderr, it will cause the package to fail. reg
is known to do this when things are successful, regedit
I am not sure about. I would suggest taking a look at the 0.9.10 beta in this case. It is fully featured and has fixed the behavior (with a switch/feature to bring it back).
Here's all the features in 0.9.10 that are completed - https://github.com/chocolatey/choco/blob/master/CHANGELOG.md
The proble not in reg, or regedit, there all is ok. Problem in downloading or checking msi file.
in ok log -
2016-04-01 09:16:21,366 [INFO ] - �������: Running 'Get-WebHeaders' with
2016-04-01 09:16:21,368 [INFO ] - url:'http://
in bad log -
2016-04-01 07:51:11,033 [DEBUG] - DEBUG: Running 'Get-WebHeaders' with
2016-04-01 07:51:11,034 [INFO ] - url:'http://
I think in bad case chocolatey can't complete Get-WebFile but not error occur.
http://<url>/package/ctios/AgentDesktopSetup-7.5.6103.msi
? What is this location? Are you trying to say something exists in the package you want to use?
Nevermind, missed that you removed the url.
I remove the domain from url before posting log here.
No worries, github hides what look like html tags by default.
I missed it until I looked at the actual words.
So you are saying there is no file downloaded when you go check?
Because the way Chocolatey works, if it can't download the file, it throws an error.
After falling i go remotely to that pc and see that file size is about 22mb, but real file on web server have about 40mb. C:\windows\TEMP\chocolatey\agent\7.5.103.1\agentInstall.msi
i also think so. but didn't
Strange why not launched Get-ChecksumValid. I think that chocolatey can crashed on download file. And no error in log.
Also think will be better not to place package directory in /lib folder before install start. On start put package directory in /lib-bad or somwhere like temp. And only if chocolatey se that chocolateyinstall.ps1 exit with exit status 0 move to /lib. Apt works on that principle.
So a few fundamental things about Chocolatey:
Install-ChocolateyInstallPackage
? https://github.com/chocolatey/choco/wiki/HelpersInstallChocolateyInstallPackageStrange why not launched Get-ChecksumValid. I think that chocolatey can crashed on download file. And no error in log.
There is likely an error, but it would have been in a previous install attempt.
Also think will be better not to place package directory in /lib folder before install start. On start put package directory in /lib-bad or somwhere like temp. And only if chocolatey se that chocolateyinstall.ps1 exit with exit status 0 move to /lib. Apt works on that principle.
Do you mean something like mark the package as pending until successful? It's likely better to talk about high level features versus implementation details. What you are requesting will break dependency resolution and upgrades as NuGet works off of the existing packages directory and not a temporary directory. We have https://github.com/chocolatey/choco/issues/383 for the pending behavior, which I believe achieves the goal of what you are requesting here.
If a file is already there, Get-ChocolateyWebFile will not redownload
I cannot reproduce this. Start install skype. cinst skype -y. at 50% download msi - disable network. chocolatey fail. Enable network, run cinst skype -y again, and chocolatey redownload msi, and sucess. What here wrong?
Do you mean something like mark the package as pending until successful?
I think this will bery good
I cannot reproduce this. Start install skype. cinst skype -y. at 50% download msi - disable network. chocolatey fail. Enable network, run cinst skype -y again, and chocolatey redownload msi, and sucess. What here wrong?
I likely should have been a bit more clear. Get-ChocolateyWebFile
does request headers to determine the size the file should be. If it receives the information it uses that to determine if the content-length is the same prior to moving forward.
and
It does look from your logs like you are doing that. However it also looks like you have multiple choco processes running at the same time making it hard to read the bad log. I think there is more to it that needs to be added to the end to see the rest of the bad install.
I'm not sure I'd recommend multiple choco processes running at the same time. And I'm not sure what is causing it because I don't know your environment.
I'm not sure I'd recommend multiple choco processes running at the same time
You dont think that will be good idea to do some like dpkg lock. And exit if choco alredy running.
It's probably a good idea to ensure that only one process runs at a time.
Now i see next problems in using chocolatey on workstations:
Now i see next problems in using chocolatey on workstations:
- Main problem - default behaviour during install packet: copying to /lib directory. If during installation pc will be rebooted or choco crashed or something else, choco will think that work done and package installed, but really don't.
- Block concurent executing choco.
This one will become a github issue - definitely worth ensuring only one is running
- Bad mechanism to controll sources from puppet.
Please be more specific?
Package has built in support for controlling source - https://forge.puppetlabs.com/chocolatey/chocolatey#source
It's the same as any other package resource with Puppet. So not bad, maybe not what you intended.
Or perhaps you mean something more like https://tickets.puppetlabs.com/browse/MODULES-3037 ?
- Hard to read chocolatey log. There to many debug information.
Perhaps a secondary log for general output that has less debugging/verbose information in it?
it's about marking the package pending.
I think it will be resolve 95% my problems with chocolatey.
Please be more specific?
I know about source in puppet, but this is not apply in my case. We have two repositories (nuget feed). One stable, and other testing. We add to specific host only atribute to be a member of class testing, and then i nedd to push to host different source to testing nuget feed. If property testing was removed, the i also need to remove testing source.
Perhaps a secondary log for general output that has less debugging/verbose information in it?
It will be nice.
Created https://github.com/chocolatey/choco/issues/682 for the secondary log.
Created #682 for the secondary log.
Also will be nice remove -dv options from puppet provider. And leave only chocolatey.log for debug information.
@bodyakov wrong repo for that discussion - see https://github.com/chocolatey/puppet-chocolatey/issues/100
I know about source in puppet, but this is not apply in my case. We have two repositories (nuget feed). One stable, and other testing. We add to specific host only atribute to be a member of class testing, and then i nedd to push to host different source to testing nuget feed. If property testing was removed, the i also need to remove testing source.
I'm still not sure what you are asking for here.
https://github.com/chocolatey/choco/issues/683 for one running choco.exe
I'm still not sure what you are asking for here.
I think i found what i need - https://github.com/chocolatey/puppet-chocolatey/pull/79
I believe I already mentioned that one, but maybe not. :+1:
Think we created issues out of everything we were fixing here. If I'm wrong feel free to comment and we can reopen this issue.
On 1% of workstation package successfully update, but msi app not.
Installed app
We are using puppet provider to update packages from private nuget repo. On some workstation msi package not update.
Output Log
bad_log https://gist.github.com/bodyakov/e71cff6c330b6983b47e0b2ec4caf9f1 ok_log https://gist.github.com/bodyakov/d4e830f8f2273724d70a38d918852276