One place for hosting & domains

      September 2020

      How to Successfully Deal With Tech Support (5 Simple Steps)

      Spoiler alert: Setting up a website can be stressful — especially if it’s your first time. And even if you’re a pro, having something go wrong with your website at one point or another is pretty much inevitable. The hard truth is that technical difficulties can make you want to throw in the towel.

      But don’t give up, champ. 

      DreamHost’s brilliant tech support team is here to get you back on track. For more than 20 years, our top priority has always been customer satisfaction, which is why our support team wins awards for quality and responsiveness

      What’s more, getting help with your website is even easier if you know what to expect when you reach out to us and what you can do on your end to make the process as quick and painless as possible. Yep, you’ve got the power!

      In this article, we’ll help you cope with your website’s technical difficulties, give you some advice for contacting technical support, and let you know what to expect when you interact with a customer service rep. 

      Want to jump ahead? Here are 5 steps to successfully dealing with tech support:

      1. Try Some Basic Solutions
      2. Document the Problem in Detail
      3. Contact the Support Team
      4. Request a Callback (If Necessary)
      5. Work with the Support Specialist to Solve the Problem

      Are you ready to uncover the secrets to getting good customer service? Let’s dive in!

      We’ll Support Your Dream

      Whatever your goals, we’ll be right there with you, making sure your site is fast, secure, and always up. Plans start at $2.59/mo.

      Step 1: Try Some Basic Solutions

      If it looks like your site has gone offline entirely, there may be a quick fix you can tackle on your own. First, check to make sure the website is genuinely down and that the issue isn’t something on your end.

      Security software may be blocking your website, especially if you’re trying to access it from a different network than usual. Maybe your cat unplugged the router. Actually, she may be trying to help, so don’t forget to check and see if the reset worked. Last but not least, have you tried turning your computer on and off again? You’re welcome, fans of The IT Crowd.

      via GIPHY

      Once you’ve eliminated other possibilities and determined that your site is down, you’ll want to know whether it’s just you or if it’s a hosting problem. You can look at the DreamHost Status page to find out if there’s a system-wide issue.

      DreamHost’s status page.

      If DreamHost is experiencing downtime, there’s no need to contact tech support, as we’re already aware of the problem. You’ll just have to sit tight until it’s over.

      If this doesn’t seem to be the source of the issue, here are a few questions to ask yourself:

      • Did you miss a hosting payment? Maybe your payment information changed and you forgot to update it. If so, once you’ve paid up, your site should be back in a few hours. 
      • Have you recently made a Domain Name Server (DNS) change? If you’ve swapped hosting providers or made a similar change, your website may be down for several hours. Patience is the solution here.
      • Did your domain expire? Perhaps life got crazy and you forgot to renew your domain. It happens. Fortunately, DreamHost gives you a 30-day grace period.
      • Are your files in the wrong place? Websites can be finicky, so if you’ve moved an important file, your site may go down. You can check on this using the website file manager.
      • Have you changed any code recently? If you suspect this is the problem, you may want to review your error log. Even if this isn’t the cause, the information may be helpful to share with tech support.

      These are just a few possibilities, but asking the above questions may help get you on the right track. 

      If you were able to pinpoint the issue, you might want to see if you can DIY your way to a solution. Troubleshooting help is available 24/7 via our Knowledge Base and blog. Or you can join our private Facebook group to swap ideas with other website owners. 

      You’re Cordially Invited

      Join DreamHost’s Facebook group to connect with like-minded website owners and get advice from peers and experts alike!

      Step 2: Document the Problem in Detail

      So you’ve done your detective work, but you still don’t know what’s wrong. It’s probably time to call in some expert help. However, before contacting support, you might want to spend some time carefully documenting the issue your website is having. Being thorough now will make it easier for tech support to get you a solution quickly.

      First, try to reproduce the issue. A problem that can’t be copied will be much more challenging to solve. If you’re able to consistently trigger the issue, you can provide more information to the DreamHost tech.

      If you’re unable to recreate the exact circumstances, try to accomplish the task in other ways. Now might be an excellent time to explore the forums. Another user may have some helpful insight or creative suggestions for how to reproduce your problem.

      You don’t need to be a tech expert to document complex issues. Just use precise language to describe what you see in as much detail as possible. If you’re vague or inaccurate, you’ll likely end up having more back and forth with the support agent.

      DreamHost’s Contact Support form improperly filled out.

      Once you’ve put together a detailed description of the issue, you’ll want to compile your website’s recent history. Identify which domain is having problems and what Content Management System (CMS) you’re using. Include any changes you made, no matter how innocent they seem — even installing a new theme or plugin can sometimes create problems.

      Additionally, you’ll want to take screenshots of what you see to support your description. A picture is worth a thousand words, especially in tech support! Bonus points apply if you can grab some video while you’re at it.

      After you’ve thoroughly documented your problem, you’ll need to gather your account information. Have your domain name and the last four digits of your password handy.

      Step 3: Contact the DreamHost Tech Support Team

      Now it’s time to contact DreamHost’s award-winning, in-house support team. You can access a technical support specialist by email or live chat. If you’re an existing customer, both of these options will be available to you through your panel on the Contact Support page. If you’re unable to log in to your DreamHost account for any reason, you’ll need to contact support using the online contact form.

      No matter which avenue you choose to get in touch, you’ll start by filling out the Contact Support form. Remember all that information we asked you to gather in the first two steps? Plug it into the form. Include your detailed description of the problem, as well as any methods you’ve tried to fix it.

      Live chat is available from 5:30 am–9:30 pm Pacific time, seven days a week. The service is available in Spanish as well. After filling out the Contact Support box, click on the Chat now button and wait for an agent to join.

      Alt-text: DreamHost’s Live Chat feature.

      Once the chat is complete, you can review it in the Contact Support page’s Recent Messages section. Keep in mind that while it may be convenient, live chat is best suited for situations with a quick fix. If your issue is more complicated, the chat agent may ask you to open a ticket via email, as this is the preferred method for contacting support.

      You can create a ticket the same way you access the live chat. The only difference is that you’ll click on the Submit a ticket button after you’ve filled out the Contact Support form.

      Once you’ve submitted your ticket, it will appear under Open Tickets. You can withdraw it if you solve the issue independently and no longer need help from tech support. Otherwise, you’ll be able to view your conversation here. 

      Step 4: Request a Callback if Necessary

      After support resolves your issue, you can still refer back to the conversation if needed. You can find the closed ticket in the Support History section of DreamPanel. You’ll also find any other messages from DreamHost here.

      The support history section of DreamPanel.

      If you need to submit a file, you can do so by selecting the Attach files link at the bottom of the form. If you prefer, you can send the file via SFTP to your DreamHost server. Just be sure to explain what you’ll be uploading and where you uploaded it.

      DreamHost’s support team doesn’t typically operate over the phone. However, callbacks may be available to you, depending on your plan. You can choose to add three callbacks per month to any plan for an additional fee.

      To access phone support, check the Request a callback box when you submit your ticket.


      The option to request a callback when contacting DreamHost tech support.

      Here, you’ll also be able to add your phone number and a preferred time. Even if you choose to have a callback, be sure to include as much information as possible when filling out the Contact Support box.

      Step 5: Work With Our Support Team to Solve Your Problem

      The DreamHost support team tries to reply to all requests within 24 hours. However, that doesn’t necessarily mean we’ll completely solve the problem at that time. You’ll be working together with a support agent to diagnose and resolve your issue. Tech support is a team effort.

      Be prepared to answer some questions and maybe even perform a few tasks to help diagnose the trouble. You’ll also be able to ask any questions that you may have. If it turns out the issue isn’t with DreamHost, our support specialists will try to point you in the right direction to get it worked out.

      Of course, it helps the entire process if everyone tries to remain calm and courteous. Glitches and technical difficulties are part of owning a website, and this likely isn’t the only time you’ll encounter frustrations. Even if you’re worried about losing traffic, it won’t help to lose your cool. You haven’t done all that yoga for nothing. Breathe.

      Remember, even if your website is experiencing significant downtime, DreamHost has a 100% uptime guarantee. You’ll receive credit for the inconvenience, and we’ll do everything we can to improve your customer experience.

      Be Awesome on the Internet

      Subscribe to our monthly newsletter for helpful tips and tricks to build your dream website!

      Great Customer Support Is a Click Away

      Handling website problems is no one’s idea of a fun time, and TBH, neither is interacting with angry customers. It’s totally normal that you’re feeling stressed out, frustrated, and maybe even embarrassed for not having the answers yourself. But before you open that bottle of wine, keep calm and contact tech support.

      Knowing what to do when complex issues arise can make the situation a little less scary. Also, planning ahead when dealing with tech support can help you get the most out of the experience. Gather as much detailed information as you can and know what channels you have available to you, as well as how to use them.

      With DreamHost’s superhero tech support team in your corner, you can build your website fearlessly. Get started with a hosting plan today!

      Source link

      Getting Into Open Source for Fun & Profit

      How to Join

      This Tech Talk is free and open to everyone. Register on Eventbrite here to receive a link to join on Thursday, October 22, 2020, 11:00 a.m.–12:00 p.m. ET.

      About the Talk

      A panel discussion featuring stories from developer advocates who took different paths along their open source journeys. Discover how developers and organizations can balance open source work with commercial work – and generate income for both yourself and your company.

      Hear from:

      • Paul Everitt, who took the first open source application server through $14 million of funding, and has bootstrapped both the Python Software Foundation and the Plone Foundation;
      • Phil Nash, author of Catch2, the 2nd most popular C++ test framework; and
      • Trisha Gee, Java Champion, published author, and expert in Java high performance systems. Trisha has developed Java applications for both for-profit and non-profit organizations of all sizes, and dabbles with open source development.

      This panel is moderated by Helen Scott, who has over 20 years’ experience in the software industry, and recently started contributing to open source.

      What You’ll Learn

      • Why, how, and when to start contributing to open source
      • Balancing open source work and commercial work
      • Generating income for both yourself and your company through open source

      This Talk is Designed For

      • Software developers
      • Organizations
      • Anyone interested in contributing to open source

      About the Presenters

      To join the live Tech Talk, register here.

      Source link

      How To Automate Jenkins Setup with Docker and Jenkins Configuration as Code

      The author selected the Wikimedia Foundation to receive a donation as part of the Write for DOnations program.


      Jenkins is one of the most popular open-source automation servers, often used to orchestrate continuous integration (CI) and/or continuous deployment (CD) workflows.

      Configuring Jenkins is typically done manually through a web-based setup wizard; this can be a slow, error-prone, and non-scalable process. You can see the steps involved by following Step 4 — Setting Up Jenkins of the How To Install Jenkins on Ubuntu 18.04 guide. Furthermore, configurations cannot be tracked in a version control system (VCS) like Git, nor be under the scrutiny of any code review process.

      In this tutorial, you will automate the installation and configuration of Jenkins using Docker and the Jenkins Configuration as Code (JCasC) method.

      Jenkins uses a pluggable architecture to provide most of its functionality. JCasC makes use of the Configuration as Code plugin, which allows you to define the desired state of your Jenkins configuration as one or more YAML file(s), eliminating the need for the setup wizard. On initialization, the Configuration as Code plugin would configure Jenkins according to the configuration file(s), greatly reducing the configuration time and eliminating human errors.

      Docker is the de facto standard for creating and running containers, which is a virtualization technology that allows you to run isolated, self-contained applications consistently across different operation systems (OSes) and hardware architectures. You will run your Jenkins instance using Docker to take advantage of this consistency and cross-platform capability.

      This tutorial starts by guiding you through setting up JCasC. You will then incrementally add to the JCasC configuration file to set up users, configuration authentication and authorization, and finally to secure your Jenkins instance. After you’ve completed this tutorial, you’ll have created a custom Docker image that is set up to use the Configuration as Code plugin on startup to automatically configure and secure your Jenkins instance.


      To complete this tutorial, you will need:

      • Access to a server with at least 2GB of RAM and Docker installed. This can be your local development machine, a Droplet, or any kind of server. Follow Step 1 — Installing Docker from one of the tutorials in the How to Install and Use Docker collection to set up Docker.

      Note: This tutorial is tested on Ubuntu 18.04; however, because Docker images are self-contained, the steps outlined here would work for any OSes with Docker installed.

      Step 1 — Disabling the Setup Wizard

      Using JCasC eliminates the need to show the setup wizard; therefore, in this first step, you’ll create a modified version of the official jenkins/jenkins image that has the setup wizard disabled. You will do this by creating a Dockerfile and building a custom Jenkins image from it.

      The jenkins/jenkins image allows you to enable or disable the setup wizard by passing in a system property named jenkins.install.runSetupWizard via the JAVA_OPTS environment variable. Users of the image can pass in the JAVA_OPTS environment variable at runtime using the --env flag to docker run. However, this approach would put the onus of disabling the setup wizard on the user of the image. Instead, you should disable the setup wizard at build time, so that the setup wizard is disabled by default.

      You can achieve this by creating a Dockerfile and using the ENV instruction to set the JAVA_OPTS environment variable.

      First, create a new directory inside your server to store the files you will be creating in this tutorial:

      • mkdir -p $HOME/playground/jcasc

      Then, navigate inside that directory:

      • cd $HOME/playground/jcasc

      Next, using your editor, create a new file named Dockerfile:

      • nano $HOME/playground/jcasc/Dockerfile

      Then, copy the following content into the Dockerfile:


      FROM jenkins/jenkins:latest
      ENV JAVA_OPTS -Djenkins.install.runSetupWizard=false

      Here, you’re using the FROM instruction to specify jenkins/jenkins:latest as the base image, and the ENV instruction to set the JAVA_OPTS environment variable.

      Save the file and exit the editor by pressing CTRL+X followed by Y.

      With these modifications in place, build a new custom Docker image and assign it a unique tag (we’ll use jcasc here):

      • docker build -t jenkins:jcasc .

      You will see output similar to the following:


      Sending build context to Docker daemon 2.048kB Step 1/2 : FROM jenkins/jenkins:latest ---> 1f4b0aaa986e Step 2/2 : ENV JAVA_OPTS -Djenkins.install.runSetupWizard=false ---> 7566b15547af Successfully built 7566b15547af Successfully tagged jenkins:jcasc

      Once built, run your custom image by running docker run:

      • docker run --name jenkins --rm -p 8080:8080 jenkins:jcasc

      You used the --name jenkins option to give your container an easy-to-remember name; otherwise a random hexadecimal ID would be used instead (e.g. f1d701324553). You also specified the --rm flag so the container will automatically be removed after you’ve stopped the container process. Lastly, you’ve configured your server host’s port 8080 to proxy to the container’s port 8080 using the -p flag; 8080 is the default port where the Jenkins web UI is served from.

      Jenkins will take a short period of time to initiate. When Jenkins is ready, you will see the following line in the output:


      ... hudson.WebAppMain$3#run: Jenkins is fully up and running

      Now, open up your browser to server_ip:8080. You’re immediately shown the dashboard without the setup wizard.

      The Jenkins dashboard

      You have just confirmed that the setup wizard has been disabled. To clean up, stop the container by pressing CTRL+C. If you’ve specified the --rm flag earlier, the stopped container would automatically be removed.

      In this step, you’ve created a custom Jenkins image that has the setup wizard disabled. However, the top right of the web interface now shows a red notification icon indicating there are issues with the setup. Click on the icon to see the details.

      The Jenkins dashboard showing issues

      The first warning informs you that you have not configured the Jenkins URL. The second tells you that you haven’t configured any authentication and authorization schemes, and that anonymous users have full permissions to perform all actions on your Jenkins instance. Previously, the setup wizard guided you through addressing these issues. Now that you’ve disabled it, you need to replicate the same functions using JCasC. The rest of this tutorial will involve modifying your Dockerfile and JCasC configuration until no more issues remain (that is, until the red notification icon disappears).

      In the next step, you will begin that process by pre-installing a selection of Jenkins plugins, including the Configuration as Code plugin, into your custom Jenkins image.

      Step 2 — Installing Jenkins Plugins

      To use JCasC, you need to install the Configuration as Code plugin. Currently, no plugins are installed. You can confirm this by navigating to http://server_ip:8080/pluginManager/installed.

      Jenkins dashboard showing no plugins are installed

      In this step, you’re going to modify your Dockerfile to pre-install a selection of plugins, including the Configuration as Code plugin.

      To automate the plugin installation process, you can make use of an installation script that comes with the jenkins/jenkins Docker image. You can find it inside the container at /usr/local/bin/ To use it, you would need to:

      • Create a text file containing a list of plugins to install
      • Copy it into the Docker image
      • Run the script to install the plugins

      First, using your editor, create a new file named plugins.txt:

      • nano $HOME/playground/jcasc/plugins.txt

      Then, add in the following newline-separated list of plugin names and versions (using the format <id>:<version>):



      Save the file and exit your editor.

      The list contains the Configuration as Code plugin, as well as all the plugins suggested by the setup wizard (correct as of Jenkins v2.251). For example, you have the Git plugin, which allows Jenkins to work with Git repositories; you also have the Pipeline plugin, which is actually a suite of plugins that allows you to define Jenkins jobs as code.

      Note: The most up-to-date list of suggested plugins can be inferred from the source code. You can also find a list of the most popular community-contributed plugins at Feel free to include any other plugins you want into the list.

      Next, open up the Dockerfile file:

      • nano $HOME/playground/jcasc/Dockerfile

      In it, add a COPY instruction to copy the plugins.txt file into the /usr/share/jenkins/ref/ directory inside the image; this is where Jenkins normally looks for plugins. Then, include an additional RUN instruction to run the script:


      FROM jenkins/jenkins
      ENV JAVA_OPTS -Djenkins.install.runSetupWizard=false
      COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
      RUN /usr/local/bin/ < /usr/share/jenkins/ref/plugins.txt

      Save the file and exit the editor. Then, build a new image using the revised Dockerfile:

      • docker build -t jenkins:jcasc .

      This step involves downloading and installing many plugins into the image, and may take some time to run depending on your internet connection. Once the plugins have finished installing, run the new Jenkins image:

      • docker run --name jenkins --rm -p 8080:8080 jenkins:jcasc

      After the Jenkins is fully up and running message appears on stdout, navigate to server_ip:8080/pluginManager/installed to see a list of installed plugins. You will see a solid checkbox next to all the plugins you’ve specified inside plugins.txt, as well as a faded checkbox next to plugins, which are dependencies of those plugins.

      A list of installed plugins

      Once you’ve confirmed that the Configuration As Code plugin is installed, terminate the container process by pressing CTRL+C.

      In this step, you’ve installed all the suggested Jenkins plugins and the Configuration as Code plugin. You’re now ready to use JCasC to tackle the issues listed in the notification box. In the next step, you will fix the first issue, which warns you that the Jenkins root URL is empty.

      Step 3 — Specifying the Jenkins URL

      The Jenkins URL is a URL for the Jenkins instance that is routable from the devices that need to access it. For example, if you’re deploying Jenkins as a node inside a private network, the Jenkins URL may be a private IP address, or a DNS name that is resolvable using a private DNS server. For this tutorial, it is sufficient to use the server’s IP address (or for local hosts) to form the Jenkins URL.

      You can set the Jenkins URL on the web interface by navigating to server_ip:8080/configure and entering the value in the Jenkins URL field under the Jenkins Location heading. Here’s how to achieve the same using the Configuration as Code plugin:

      1. Define the desired configuration of your Jenkins instance inside a declarative configuration file (which we’ll call casc.yaml).
      2. Copy the configuration file into the Docker image (just as you did for your plugins.txt file).
      3. Set the CASC_JENKINS_CONFIG environment variable to the path of the configuration file to instruct the Configuration as Code plugin to read it.

      First, create a new file named casc.yaml:

      • nano $HOME/playground/jcasc/casc.yaml

      Then, add in the following lines:


          url: http://server_ip:8080/

      unclassified.location.url is the path for setting the Jenkins URL. It is just one of a myriad of properties that can be set with JCasC. Valid properties are determined by the plugins that are installed. For example, the jenkins.authorizationStrategy.globalMatrix.permissions property would only be valid if the Matrix Authorization Strategy plugin is installed. To see what properties are available, navigate to server_ip:8080/configuration-as-code/reference, and you’ll find a page of documentation that is customized to your particular Jenkins installation.

      Save the casc.yaml file, exit your editor, and open the Dockerfile file:

      • nano $HOME/playground/jcasc/Dockerfile

      Add a COPY instruction to the end of your Dockerfile that copies the casc.yaml file into the image at /var/jenkins_home/casc.yaml. You’ve chosen /var/jenkins_home/ because that’s the default directory where Jenkins stores all of its data:


      FROM jenkins/jenkins:latest
      ENV JAVA_OPTS -Djenkins.install.runSetupWizard=false
      COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
      RUN /usr/local/bin/ < /usr/share/jenkins/ref/plugins.txt
      COPY casc.yaml /var/jenkins_home/casc.yaml

      Then, add a further ENV instruction that sets the CASC_JENKINS_CONFIG environment variable:


      FROM jenkins/jenkins:latest
      ENV JAVA_OPTS -Djenkins.install.runSetupWizard=false
      ENV CASC_JENKINS_CONFIG /var/jenkins_home/casc.yaml
      COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
      RUN /usr/local/bin/ < /usr/share/jenkins/ref/plugins.txt
      COPY casc.yaml /var/jenkins_home/casc.yaml

      Note: You’ve put the ENV instruction near the top because it’s something that you are unlikely to change. By placing it before the COPY and RUN instructions, you can avoid invalidating the cached layer if you were to update the casc.yaml or plugins.txt.

      Save the file and exit the editor. Next, build the image:

      • docker build -t jenkins:jcasc .

      And run the updated Jenkins image:

      • docker run --name jenkins --rm -p 8080:8080 jenkins:jcasc

      As soon as the Jenkins is fully up and running log line appears, navigate to server_ip:8080 to view the dashboard. This time, you may have noticed that the notification count is reduced by one, and the warning about the Jenkins URL has disappeared.

      Jenkins Dashboard showing the notification counter has a count of 1

      Now, navigate to server_ip:8080/configure and scroll down to the Jenkins URL field. Confirm that the Jenkins URL has been set to the same value specified in the casc.yaml file.

      Lastly, stop the container process by pressing CTRL+C.

      In this step, you used the Configuration as Code plugin to set the Jenkins URL. In the next step, you will tackle the second issue from the notifications list (the Jenkins is currently unsecured message).

      Step 4 — Creating a User

      So far, your setup has not implemented any authentication and authorization mechanisms. In this step, you will set up a basic, password-based authentication scheme and create a new user named admin.

      Start by opening your casc.yaml file:

      • nano $HOME/playground/jcasc/casc.yaml

      Then, add in the highlighted snippet:


            allowsSignup: false
             - id: ${JENKINS_ADMIN_ID}
               password: ${JENKINS_ADMIN_PASSWORD}

      In the context of Jenkins, a security realm is simply an authentication mechanism; the local security realm means to use basic authentication where users must specify their ID/username and password. Other security realms exist and are provided by plugins. For instance, the LDAP plugin allows you to use an existing LDAP directory service as the authentication mechanism. The GitHub Authentication plugin allows you to use your GitHub credentials to authenticate via OAuth.

      Note that you’ve also specified allowsSignup: false, which prevents anonymous users from creating an account through the web interface.

      Finally, instead of hard-coding the user ID and password, you are using variables whose values can be filled in at runtime. This is important because one of the benefits of using JCasC is that the casc.yaml file can be committed into source control; if you were to store user passwords in plaintext inside the configuration file, you would have effectively compromised the credentials. Instead, variables are defined using the ${VARIABLE_NAME} syntax, and its value can be filled in using an environment variable of the same name, or a file of the same name that’s placed inside the /run/secrets/ directory within the container image.

      Next, build a new image to incorporate the changes made to the casc.yaml file:

      • docker build -t jenkins:jcasc .

      Then, run the updated Jenkins image whilst passing in the JENKINS_ADMIN_ID and JENKINS_ADMIN_PASSWORD environment variables via the --env option (replace <password> with a password of your choice):

      • docker run --name jenkins --rm -p 8080:8080 --env JENKINS_ADMIN_ID=admin --env JENKINS_ADMIN_PASSWORD=password jenkins:jcasc

      You can now go to server_ip:8080/login and log in using the specified credentials.

      Jenkins Login Screen with the user ID and password fields populated

      Once you’ve logged in successfully, you will be redirected to the dashboard.

      Jenkins Dashboard for authenticated user, showing the user ID and a 'log out' link near the top right corner of the page

      Finish this step by pressing CTRL+C to stop the container.

      In this step, you used JCasC to create a new user named admin. You’ve also learned how to keep sensitive data, like passwords, out of files tracked by VCSs. However, so far you’ve only configured user authentication; you haven’t implemented any authorization mechanisms. In the next step, you will use JCasC to grant your admin user with administrative privileges.

      Step 5 — Setting Up Authorization

      After setting up the security realm, you must now configure the authorization strategy. In this step, you will use the Matrix Authorization Strategy plugin to configure permissions for your admin user.

      By default, the Jenkins core installation provides us with three authorization strategies:

      • unsecured: every user, including anonymous users, have full permissions to do everything
      • legacy: emulates legacy Jenkins (prior to v1.164), where any users with the role admin is given full permissions, whilst other users, including anonymous users, are given read access.

      Note: A role in Jenkins can be a user (for example, daniel) or a group (for example, developers)

      • loggedInUsersCanDoAnything: anonymous users are given either no access or read-only access. Authenticated users have full permissions to do everything. By allowing actions only for authenticated users, you are able to have an audit trail of which users performed which actions.

      Note: You can explore other authorization strategies and their related plugins in the documentation; these include plugins that handle both authentication and authorization.

      All of these authorization strategies are very crude, and does not afford granular control over how permissions are set for different users. Instead, you can use the Matrix Authorization Strategy plugin that was already included in your plugins.txt list. This plugin affords you a more granular authorization strategy, and allows you to set user permissions globally, as well as per project/job.

      The Matrix Authorization Strategy plugin allows you to use the jenkins.authorizationStrategy.globalMatrix.permissions JCasC property to set global permissions. To use it, open your casc.yaml file:

      • nano $HOME/playground/jcasc/casc.yaml

      And add in the highlighted snippet:


             - id: ${JENKINS_ADMIN_ID}
               password: ${JENKINS_ADMIN_PASSWORD}
              - "Overall/Administer:admin"
              - "Overall/Read:authenticated"

      The globalMatrix property sets global permissions (as opposed to per-project permissions). The permissions property is a list of strings with the format <permission-group>/<permission-name>:<role>. Here, you are granting the Overall/Administer permissions to the admin user. You’re also granting Overall/Read permissions to authenticated, which is a special role that represents all authenticated users. There’s another special role called anonymous, which groups all non-authenticated users together. But since permissions are denied by default, if you don’t want to give anonymous users any permissions, you don’t need to explicitly include an entry for it.

      Save the casc.yaml file, exit your editor, and build a new image:

      • docker build -t jenkins:jcasc .

      Then, run the updated Jenkins image:

      • docker run --name jenkins --rm -p 8080:8080 --env JENKINS_ADMIN_ID=admin --env JENKINS_ADMIN_PASSWORD=password jenkins:jcasc

      Wait for the Jenkins is fully up and running log line, and then navigate to server_ip:8080. You will be redirected to the login page. Fill in your credentials and you will be redirected to the main dashboard.

      In this step, you have set up global permissions for your admin user. However, resolving the authorization issue uncovered additional issues that are now shown in the notification menu.

      Jenkins Dashboard showing the notifications menu with two issues

      Therefore, in the next step, you will continue to modify your Docker image, to resolve each issue one by one until none remains.

      Before you continue, stop the container by pressing CTRL+C.

      Step 6 — Setting Up Build Authorization

      The first issue in the notifications list relates to build authentication. By default, all jobs are run as the system user, which has a lot of system privileges. Therefore, a Jenkins user can perform privilege escalation simply by defining and running a malicious job or pipeline; this is insecure.

      Instead, jobs should be ran using the same Jenkins user that configured or triggered it. To achieve this, you need to install an additional plugin called the Authorize Project plugin.

      Open plugins.txt:

      • nano $HOME/playground/jcasc/plugins.txt

      And add the highlighted line:



      The plugin provides a new build authorization strategy, which you would need to specify in your JCasC configuration. Exit out of the plugins.txt file and open the casc.yaml file:

      • nano $HOME/playground/jcasc/casc.yaml

      Add the highlighted block to your casc.yaml file:


              - "Overall/Administer:admin"
              - "Overall/Read:authenticated"
          - global:
              strategy: triggeringUsersAuthorizationStrategy

      Save the file and exit the editor. Then, build a new image using the modified plugins.txt and casc.yaml files:

      • docker build -t jenkins:jcasc .

      Then, run the updated Jenkins image:

      • docker run --name jenkins --rm -p 8080:8080 --env JENKINS_ADMIN_ID=admin --env JENKINS_ADMIN_PASSWORD=password jenkins:jcasc

      Wait for the Jenkins is fully up and running log line, then navigate to server_ip:8080/login, fill in your credentials, and arrive at the main dashboard. Open the notification menu, and you will see the issue related to build authentication no longer appears.

      Jenkins dashboard's notification menu showing a single issue related to agent to master security subsystem being turned off

      Stop the container by running CTRL+C before continuing.

      In this step, you have configured Jenkins to run builds using the user that triggered the build, instead of the system user. This eliminates one of the issues in the notifications list. In the next step, you will tackle the next issue related to the Agent to Controller Security Subsystem.

      Step 7 — Enabling Agent to Controller Access Control

      In this tutorial, you have deployed only a single instance of Jenkins, which runs all builds. However, Jenkins supports distributed builds using an agent/controller configuration. The controller is responsible for providing the web UI, exposing an API for clients to send requests to, and co-ordinating builds. The agents are the instances that execute the jobs.

      The benefit of this configuration is that it is more scalable and fault-tolerant. If one of the servers running Jenkins goes down, other instances can take up the extra load.

      However, there may be instances where the agents cannot be trusted by the controller. For example, the OPS team may manage the Jenkins controller, whilst an external contractor manages their own custom-configured Jenkins agent. Without the Agent to Controller Security Subsystem, the agent is able to instruct the controller to execute any actions it requests, which may be undesirable. By enabling Agent to Controller Access Control, you can control which commands and files the agents have access to.

      To enable Agent to Controller Access Control, open the casc.yaml file:

      • nano $HOME/playground/jcasc/casc.yaml

      Then, add the following highlighted lines:


              - "Overall/Administer:admin"
              - "Overall/Read:authenticated"
          enabled: true

      Save the file and build a new image:

      • docker build -t jenkins:jcasc .

      Run the updated Jenkins image:

      • docker run --name jenkins --rm -p 8080:8080 --env JENKINS_ADMIN_ID=admin --env JENKINS_ADMIN_PASSWORD=password jenkins:jcasc

      Navigate to server_ip:8080/login and authenticate as before. When you land on the main dashboard, the notifications menu will not show any more issues.

      Jenkins dashboard showing no issues


      You’ve now successfully configured a simple Jenkins server using JCasC. Just as the Pipeline plugin enables developers to define their jobs inside a Jenkinsfile, the Configuration as Code plugin enables administrators to define the Jenkins configuration inside a YAML file. Both of these plugins bring Jenkins closer aligned with the Everything as Code (EaC) paradigm.

      However, getting the JCasC syntax correct can be difficult, and the documentation can be hard to decipher. If you’re stuck and need help, you may find it in the Gitter chat for the plugin.

      Although you have configured the basic settings of Jenkins using JCasC, the new instance does not contain any projects or jobs. To take this even further, explore the Job DSL plugin, which allows us to define projects and jobs as code. What’s more, you can include the Job DSL code inside your JCasC configuration file, and have the projects and jobs created as part of the configuration process.

      Source link