ferventcoder
commented
6 years ago Administrator Information currently says "The ApiKey for this repository is set to xxxxx Please set that using the setapikey command above, substituting that value for '{apikey}'. " but needs instructions on where to set the apikey for the server, i.e. edit web.config and look for...
Since we have that covered under #25, let's keep that discussion there.
For everything else. I get you need a place to get all of your ideas down and that's good. However, once you have that, please create issues in manageable separate chunks (we can help with that). For each piece that provides a specific piece of value being able to be released on its own, that is a separate issue/ticket IMHO. So let's start looking at how we can add votes and comments to existing issues here and how we can add new issues for the specific items here that don't exist. Does that sound fair?
bcurran3
I'm glad Chocolatey Simple Server exists. It's aptly named. Installing it is fairly simple, but since there are 432 downloads and sparse documentation with not much info on configuration and use, I'm very surprised there aren't 432x~2 questions about it. :)
My suggestions:
Administrator Information currently says "The ApiKey for this repository is set to xxxxx Please set that using the setapikey command above, substituting that value for '{apikey}'. " but needs instructions on where to set the apikey for the server, i.e. edit web.config and look for...
Repository URLs currently says "In the package manager settings, add the following URL to the list of Package Sources: " The choco command to do that should be added and follow the format of the following two statements and examples.
It should be noted that you can't push and overwrite (same version) packages, you must delete the existing package first. "Failed to process request. 'Not Acceptable'. The remote server returned an error: (406) Not Acceptable.." was scary until I figured it out. The ability to overwrite would be preferred to me. If this is somehow deemed a security problem, OK, make it a configurable setting on the server please.
It is stated where you can add packages, but it's not necessarily intuitive. I recommend some verbiage massaging to make the message more clear that you can directly copy package files to the xxxx folder without having to push them and that the server will automatically find them and make them available. Don't forget to update the chocolatey.server\app_data\Packages\Readme.txt file too!
"To add packages to the feed put package files (.nupkg files) in the folder "D:\chocolatey.server\App_Data\Packages"." - it would be useful if the location was a link so I could click it and have Explorer pop up there.
Related to above, it should be stated where to delete packages. Probably combining is best, "To add packages to the feed or delete them, go to...."
It should be noted that viewing packages via http://servername/chocolatey/Packages will fail on Chrome and it is recommend to use a different browser. If a workaround such as a Chrome extension is available to display the XML as a web page like we expect, it should be noted as well.
/Packages list DESPERATELY needs package versions displayed!
A delete package button from the /Packages list would be nice.
Clicking the package name and being able to view the full description would be nice.
(Yeah, I know. Those are obvious future roadmap items.)
Something should be noted on what "Click here to clear the package cache." actually does. Yeah, it's probably clear to you Mr Chocolatey, but new Chocolatey Simple Server admins might think, "I better not click that. I don't want it to delete all my packages or something bad." Just some small info stating under what conditions it's useful and/or recommended to clear the package cache. Then something saying Chocolatey Simple Server will rebuild the cache automatically. Cache re-population will be fast on small repositories but might take some time on large repositories (xxxxxxx packages). Honestly, I have no clue if my examples hold true or not, it's all guess work, no documentation. :) I do see the servername.cache.bin file though.
It should be noted about using HTTP versus HTTPS in the documentation instead of just finding out about it when trying to push a package over HTTP.
I created a self-signed cert for my inhouse test Chocolatey Simple Server. I tried to push a package and got error "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel." Since it's self-signed of course I get not trusted errors in Firefox too. I'll probably delete, recreate, and try again. Adding info about this subject would be helpful in the documentation. Adding configurable levels of security including a lower level one that doesn't care if a self-signed cert was found to choco would be awesome. (My Exchange server has a real cert, but I'd rather keep Chocolatey Simple Server on my apps server which otherwise doesn't need a cert.)
Already mentioned, but package parameter for where to install Chocolatey Simple Server is needed. I don't keep data on the C: drive of ANY of my servers, yet the tools dir is very useful to keep on C:.
It would be useful to notate how choco prioritizes sources. I'm pretty sure anyone setting up Chocolatey Simple Server is going to have the community feed as a source. Then they're going to add their local Chocolatey Simple Server as a source. So if you push a package to your local server that is also in the community repository, which one will cinst use? I'm assuming it searches in the order listed in the chocolatey.config, meaning it will by default download from the community repository first. Assuming this is true, most people running and using Chocolatey Simple Server internally would probably want to have their local repository searched first and the community repository searched second (if at all). This is probably documented elsewhere, but should be replicated and re-written with Chocolatey Simple Server in mind or at the very least hotlinked.
Related to above and I'll have to post in the choco issues... In the case of multiple sources in chocolatey.config it would be useful to display WHICH source is being used when choco installs a package; i.e I push a package to the community feed and my local Chocolatey Simple Server. I later edit the package and push it to one of the feeds. Right before I push it to the other server I get distracted by lunch. I come back forgetting everything I did before because I'm in a food coma as well as short term memory loss. I CINST the package and get results I didn't expect because the third revision of package xxx vx.x is on the local server but the second revision of package xxx vx.x was used from the community feed. So "Chocolatey v0.10.8 Professional Installing the following packages: test-package" would be nice instead to say "test-package from source https://theetherverse." Of course if only one source is configured it wouldn't need to display anything different for the masses then it currently does. Sure, maybe this enhancement should be a C4B issue.
Take the above suggestion and duplicate that idea for clist. Sure, I can tell clist -s "'https://somewhere/out/there'", if I can remember it, to view packages from one source. It would be useful to have a -ss (show sources) option so that I could CLIST -L -SS (or something) to list all installed packages and where they came from.
The current "Setup Normally" documentation states "Disable or remove the Default website" It should be noted why; or more importantly how to make Chocolatey Simple Server coexist with pre-existing production web servers. I tested and now am using on a new IIS installation I'm sure a lot of people don't want to setup a new server just for Chocolatey Simple Server if they don't need to.
I'm glad I got that out of my system. Now maybe I can sleep peacefully! That's all I can think of at the moment, I'm sure I've got more. :)
Keep up the good work and evolution of that work.
Let me know what to break out of here and move elsewhere.