-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question on Documentation of Install procedures. #51
Comments
Here's what I have for now. It worked when I installed it @ 2 weeks ago. Remember it's a work in progress :)
New-NetFirewallRule -Name "Tug Inbound" -DisplayName "Tug Inbound" -Enabled True -Direction Inbound -Protocol TCP -RemoteAddress any -LocalPort 5000 |
Is there future development planned to make this an entirely offline installation? |
@bobbytreed -- how do you mean? In terms of being able to just download an installation package that you can install separately? The steps that @majst32 provided were for being able to setup to build the software in your local environment, they are not the way that an end-user would ultimately use to install a Tug server for say production use. We're just very early on in the development cycle so a formal installation process hasn't been developed yet. |
@bobbytreed, if you're just interested in getting Tug installed locally to start playing around, please take a look at these steps to install a pre-release bundle that is powered by a set of PowerShell cmdlets which you can tailor for basic operation. @majst32 is testing this process out right now and has had good luck with it, and I will formally document and release this as one of the first packages shortly. If you go this route, please do provide any feedback on documentation, installation/upgrade process, ease of use and configuration, etc. |
Yes, sorry for the slow response. The instructions provided were the set of down-and-dirty instructions that I did get to work, by no means were they optimized. I just knew they worked. But as @ebekker stated above, the pre-release bundle is the way to go. This wasn't available yet when I wrote the above instructions. While the bundle still requires internet access, the module can be downloaded to a machine that has internet access and then redistributed by whatever means you would distribute other PowerShell modules such as xPSDesiredStateConfiguration. HTH |
My two cents, it is still incredibly unclear to me how I'm supposed to step from the version installed using the PowerShell module to using IIS. Also the How To Deploy link in the project wiki doesn't go anywhere. |
@Chirishman, I assume you've looked at this README, correct? There is a reference/link there to this explanation of how to configure IIS to proxy for ASP.NET Core 1.x application. Unfortunately, the existing installation bundle that has been published to the nuget feed is the original ASP.NET Core 1.x code base. That version did not support Kestrel being the direct HTTP interface to an ASP.NET app unless it was operating in a trusted environment (e.g. a private, trusted network). I'm working on migrating all of the existing code base from .NET Core 1.x to 2.0 right now. I've finished a few of the core libraries already, and then I'll work on building a new bundle and installation module which I'll publish to the PS Gallery. Once the 2.x version is published you can actually operate that version without IIS -- that is a fully supported and sanctioned configuration with the 2.0 version of Kestrel. However, if you still want or need to front that with IIS, you will still need to follow the directions in that link (just be sure you follow the 2.0 version of the instructions). |
After speaking with Don on Friday, I know that the documentation is still in the works, but do you have a rough guide for deploying the solution? Don mentioned that I should reach out to @majst32
The text was updated successfully, but these errors were encountered: