Answers: <p>For your own personal use, I think a GitHub repository with all of your bootstrap and installation scripts is a great idea. It serves as a portable way to download and distribute any scripts you need where firewalls and restrictions aren't an issue. </p>
  
  <p>As for within your organization, one suggestion that your IT might be open to as a compromise is to create a machine (barebones, VM, etc.) that is solely dedicated to downloading and storing the artifacts that you need. The criteria for this machine would be:</p>
  
  <ol>
  <li>It has access to download artifacts (files, apps, etc.) from a source (preferably either the open internet or from white-listed addresses).</li>
  <li>It is able to store the artifacts in a central location.</li>
  <li>It is not able to access internal infrastructure</li>
  <li>It is has auditing to track any artifacts that it downloads/stores</li>
  </ol>
  
  <p>With this setup, you could download something like the latest version of Python onto the server (via logging in with credentials, API, etc.) and have it store Python in a central location for your other servers to download and install. You could store your artifacts in a multitude of ways (artifact repository, cloud storage, file server, etc.), but only that server should be able to upload to your storage. Your IT team could even set alerts when a new artifact is downloaded on this server or uploaded to your storage so that they can inspect it. </p>
  
  <p>I think this approach demonstrates a few things to your IT department:</p>
  
  <ol>
  <li>These artifacts are important enough to you and your teams that you are willing to go out of your way to establish a safer and more traceable method to retrieve them.</li>
  <li>You have given your IT department an automated way to track who and when an artifact was downloaded in the event an artifact is malicious and needs to be deleted and traced to a source (something they probably didn't have in place before).</li>
  <li>The method you propose not only gives you more accessibility to the tools you need to be productive, but you are proposing ways to help your IT team be more productive by not having to manage all aspects of downloading artifacts. </li>
  </ol>
  
Answers: CC BY-SA 3.0
Answers: 2018-02-03T15:25:06.847Z
Answers: There are some great points here, but this doesn't answer the question. The company I work for has already built this facility (this is how we get external software into the company) my issue with it is that you naturally have to request each component again each time, wait for an approval workflow to complete etc & then same again with updates (albeit slightly faster).
  
  What I wanted to do was package my applications up into a single file and then use this same mechanism to request this single file (and updates, as needed).
Answers: xeijin
Answers: CC BY-SA 3.0
Answers: 2018-01-30T22:01:43.667Z
Answers: 2018-01-30T22:01:43.667Z
Answers: Preston Martin
Body: <p>I've discovered a number of open source tools over the years which have become an essential part of my personal workflow &amp; productivity in my current day job (project manager / business analyst). I can often move from company-to-company and even account/machine (and OS too) and want to get up and running with the minimum of fuss.</p>
  <p>What I'm trying to combine:</p>
  <ul>
  <li><strong><a href="https://github.com/xeijin/propositum#components" rel="noreferrer">apps/tools</a></strong> (which use a variety of frameworks and languages including python, flask, javascript, node, java etc)</li>
  <li><strong>config files</strong></li>
  <li><strong>other misc. files</strong> (e.g. fonts)</li>
  </ul>
  <p><strong>However, by necessity, I am often behind corporate firewalls and restrictive IT policies</strong> which make it time-consuming to get internal license approvals for each tool, download each of the tools individually, keep them up-to-date, blocked external package repos, maintaining &amp; building-upon the associated configuration files over time...</p>
  <h3>Docker is the obvious solution here, but...</h3>
  <h3>... it is often blocked by these same IT policies, as are its alternatives.</h3>
  <h1>What I've tried</h1>
  <p>Using a <strong><a href="https://github.com/xeijin/propositum" rel="noreferrer">GitHub repository</a></strong>, I've since settled on building/installing everything locally, making it 'portable' (using batch scripts, symlinks and a number of config file tweaks) and then uploading.</p>
  <p>Drawbacks of this approach include: the complexity, difficulty maintaining this cross-platform (currently windows-only), working around applications installed via git-clone, working around quirks of 'portable' versions of runtime dependencies like Python, github 50mb single file-size limits...</p>
  <h1>Another possible approach I considered</h1>
  <p><strong>Using continuous integration</strong> (like Travis-CI and AppVeyor), my main concern here is that I've not actually 'built' some of the apps I use (e.g. emacs-w64, which I download the pre-built binaries for) so wondering if this will just add more complexity than my current solution ... and since Travis-CI doesn't support windows it adds an additional dependency, as well as the overhead of learning the continuous integration world &amp; maintaining build scripts for linux, osx &amp; windows..</p>
  <p>I'm not looking to open up discussion here, but an answer that will meet my needs with the minimum of fuss (this is for personal use rather than devops for my company / others after all) from the experts ... even if the answer is simply that I need to put the effort into a CI solution...</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-01-20T15:13:58.463Z
Comments: One note: personally using a tool to do job-related work while employed of a company, sometimes even installing it on a company-provided machine doesn't typically qualify as personal use from the licensing prospective. Check the respective licensing agreements.
Comments: Dan Cornilescu
Comments: CC BY-SA 3.0
Comments: 2018-01-20T15:57:40.087Z
Comments: Agreed, which is why I've tried to stick to open source tools with licenses that are permissive in the context of usage as a 'standalone tool' (Apache, MIT, GPL etc). The tools will never be linked with company code, and the licenses meet the quite restrictive terms for software acquisitions at one of the larger companies I've worked for.
Comments: xeijin
Comments: CC BY-SA 3.0
Comments: 2018-01-20T19:32:49.480Z
Comments: I do the same as you - I have a github repository for my ~/.emacs.d; and a Vagrantfile which spins up a Linux box with my favourite tools. I do not use Win10 (nor did I encounter it at work so far), so Docker is out. And Vagrant obviously needs some VM provider, which means local admin permissions, probably. I'm looking forward to answers that tell us how to do it better, I have not found a more complete solution yet.
Comments: AnoE
Tags: <windows><configuration><methodology>
Title: How can I build & maintain a personal, cross-platform 'toolkit' of commonly used applications?
UserDisplayName: xeijin
ThreadText: # How can I build & maintain a personal, cross-platform 'toolkit' of commonly used applications?
  
  (Asked by: username_0 on 2018-01-20)
  
  I've discovered a number of open source tools over the years which have become an essential part of my personal workflow & productivity in my current day job (project manager / business analyst). I can often move from company-to-company and even account/machine (and OS too) and want to get up and running with the minimum of fuss.
  
  What I'm trying to combine:
  
  * **[apps/tools](https://github.com/username_0/propositum#components)** (which use a variety of frameworks and languages including python, flask, javascript, node, java etc)
  * **config files**
  * **other misc. files** (e.g. fonts)
  
  **However, by necessity, I am often behind corporate firewalls and restrictive IT policies** which make it time-consuming to get internal license approvals for each tool, download each of the tools individually, keep them up-to-date, blocked external package repos, maintaining & building-upon the associated configuration files over time...
  
  ### Docker is the obvious solution here, but...
  
  ### ... it is often blocked by these same IT policies, as are its alternatives.
  
  # What I've tried
  
  Using a **[GitHub repository](https://github.com/username_0/propositum)**, I've since settled on building/installing everything locally, making it 'portable' (using batch scripts, symlinks and a number of config file tweaks) and then uploading.
  
  Drawbacks of this approach include: the complexity, difficulty maintaining this cross-platform (currently windows-only), working around applications installed via git-clone, working around quirks of 'portable' versions of runtime dependencies like Python, github 50mb single file-size limits...
  
  # Another possible approach I considered
  
  **Using continuous integration** (like Travis-CI and AppVeyor), my main concern here is that I've not actually 'built' some of the apps I use (e.g. emacs-w64, which I download the pre-built binaries for) so wondering if this will just add more complexity than my current solution ... and since Travis-CI doesn't support windows it adds an additional dependency, as well as the overhead of learning the continuous integration world & maintaining build scripts for linux, osx & windows..
  
  I'm not looking to open up discussion here, but an answer that will meet my needs with the minimum of fuss (this is for personal use rather than devops for my company / others after all) from the experts ... even if the answer is simply that I need to put the effort into a CI solution...
  
  **Tags:** windows, configuration, methodology
  
  > **Comments:**
  > **username_1**: One note: personally using a tool to do job-related work while employed of a company, sometimes even installing it on a company-provided machine doesn't typically qualify as personal use from the licensing prospective. Check the respective licensing agreements.  
  > **username_0**: Agreed, which is why I've tried to stick to open source tools with licenses that are permissive in the context of usage as a 'standalone tool' (Apache, MIT, GPL etc). The tools will never be linked with company code, and the licenses meet the quite restrictive terms for software acquisitions at one of the larger companies I've worked for.  
  > **username_2**: I do the same as you - I have a github repository for my ~/.emacs.d; and a Vagrantfile which spins up a Linux box with my favourite tools. I do not use Win10 (nor did I encounter it at work so far), so Docker is out. And Vagrant obviously needs some VM provider, which means local admin permissions, probably. I'm looking forward to answers that tell us how to do it better, I have not found a more complete solution yet.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2018-01-30. Score: 1
  
  For your own personal use, I think a GitHub repository with all of your bootstrap and installation scripts is a great idea. It serves as a portable way to download and distribute any scripts you need where firewalls and restrictions aren't an issue.
  
  As for within your organization, one suggestion that your IT might be open to as a compromise is to create a machine (barebones, VM, etc.) that is solely dedicated to downloading and storing the artifacts that you need. The criteria for this machine would be:
  
  1. It has access to download artifacts (files, apps, etc.) from a source (preferably either the open internet or from white-listed addresses).
  2. It is able to store the artifacts in a central location.
  3. It is not able to access internal infrastructure
  4. It is has auditing to track any artifacts that it downloads/stores
  
  With this setup, you could download something like the latest version of Python onto the server (via logging in with credentials, API, etc.) and have it store Python in a central location for your other servers to download and install. You could store your artifacts in a multitude of ways (artifact repository, cloud storage, file server, etc.), but only that server should be able to upload to your storage. Your IT team could even set alerts when a new artifact is downloaded on this server or uploaded to your storage so that they can inspect it.
  
  I think this approach demonstrates a few things to your IT department:
  
  1. These artifacts are important enough to you and your teams that you are willing to go out of your way to establish a safer and more traceable method to retrieve them.
  2. You have given your IT department an automated way to track who and when an artifact was downloaded in the event an artifact is malicious and needs to be deleted and traced to a source (something they probably didn't have in place before).
  3. The method you propose not only gives you more accessibility to the tools you need to be productive, but you are proposing ways to help your IT team be more productive by not having to manage all aspects of downloading artifacts.
  
  > **Comments:**
  > **username_0**: There are some great points here, but this doesn't answer the question. The company I work for has already built this facility (this is how we get external software into the company) my issue with it is that you naturally have to request each component again each time, wait for an approval workflow to complete etc & then same again with updates (albeit slightly faster).  What I wanted to do was package my applications up into a single file and then use this same mechanism to request this single file (and updates, as needed).  
  
  ---
  
  