quickshiftin's questions

I'm using ConfigMap to expose a php file intended to be shared across pods and writable by the www-data (Apache) user.

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: magento-config
data:
  env.php: |
    <?php
    return array ( ...

Deployment

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: apache-deployment
spec:
    ...
    spec:
      containers:
        - name: apache
          image: apache:2.4
          ...
          volumeMounts:
          - name: magento-configs
            mountPath: /var/www/html/etc
          imagePullPolicy: Always
      volumes:
        - name: magento-configs
          configMap:
            name: magento-config

The file appears writable only by root though

root@apache-deployment-79c8548cdc-r6qhs:/# realpath /var/www/html/etc/env.php
/var/www/html/etc/..2018_04_23_16_21_10.435323593/env.php
root@apache-deployment-79c8548cdc-r6qhs:/# ls -l /var/www/html/etc/..2018_04_23_16_21_10.435323593/env.php
-rw-r--r-- 1 root root 909 Apr 23 16:21

Is there any way to change this? I noticed VolumeMount has a readOnly property which defaults to false. Indeed the volume is writable, but only by root.

I tried setting APACHE_RUN_USER to root in Apache, but it wants me to recompile (currently using build from apt) lol, which feels like the wrong direction. I'd like to just figure out how to use ConfigMap correctly if possible.

If I'm running Wordpress in a Kubernetes environment, whereby the code is part of a Docker image and someone tries to add a plugin through the Wordpress admin, I don't expect that will work very well, as the plugin will only be installed on the container that's hit when they add the plugin, right?

Is my approach of building the code into an image a misstep? Another approach I'd considered was a volume that holds the code, which would handle this use case well. Is there a discussion of such things I could read somewhere?

I'm trying to setup a trivial private repository using the official registry image and kwk/docker-registry-frontend as a frontend.

My docker run command for the registry

docker run -d -p 127.0.0.1:5000:5000 \
--restart=always \
--name registry \
registry:2

My docker run command for the frontend

docker run \
-d \
--name registry-frontend \
-e ENV_DOCKER_REGISTRY_HOST=127.0.0.1 \
-e ENV_DOCKER_REGISTRY_PORT=5000 \
-p 192.168.88.142:80:80 \
konradkleine/docker-registry-frontend:v2

I can push images to the repository directly:

docker tag some-local-image localhost:50000/my-name/my-local-image
docker push localhost:50000/my-name/my-local-image

When I navigate to the frontend in my browser (http://192.168.88.142), the frontend loads, however the image is not listed...

This seems about the most basic setup possible; what am I missing?

I have a password for an SMTP relay server with a dollar sign in it. How to enter this into main.cf without postfix thinking it's a variable?

I see nothing here about escaping dollar signs. I randomly tried putting a backslash in front of the dollar sign and double quotes around it to no avail.

Any ideas?

I've read how to, and successfully created and export of my configuration. The documentation says the exports can be downloaded via FTP, but provide no details.

Anybody know how to download an export?

Is it possible to define a separate hiera.yaml for a given environment? Currently I am using dynamic environments. Each one has its own hiera data directory, per my hiera.yaml file.

:yaml:
   :datadir: /var/lib/hiera/%{environment}

One drawback though is all of these environments are subject to the same hierarchy. I don't think this would work very well with many teams on a shared Puppet master.

So what is the best option, a dedicated Puppet master for each team that has a set of servers to maintain?

We're using Git as our VCS and RPMs for packaging. I'd like to store the Git hash a package was built from, but I'm not sure on the most appropriate place.

There are a number of tags available to an RPM, however I don't see any for a VCS version (maybe glanced over it?).

I'm quite leery about adding a custom tag, just looking at the 50,000 ft level.

One solution that feels pretty hacky would be to put the Git hash in the description field. We're not using it for anything else at this point, but wow, that just feels ugly.

So what is the most appropriate place to store a VCS version in an RPM?

I'm looking for clarification here. It seems the managehome attribute of the user defined type only works when the user doesn't exist. Have a look at this DSL

user { 'artifactory':
        ensure     => 'present',
        home       => '/home/artifactory',
        managehome => true,
}

file { '/home/artifactory/data':
        ensure  => link,
        target  => '/var/lib',
        require => User['artifactory'],
}

The first time I run this it works fine, however, if I delete the artifactory user's home directory, then run it again, puppet barfs.

Error: Could not set 'link' on ensure: No such file or directory

My first thought is really? Take a look at the documentation

Whether to manage the home directory when managing the user. This will create the home directory when ensure => present

If I delete the user and try again it works. So is this by design or is it a bug? It seems delicate to me.

I'm using the yumrepo built-in type. I can get a basic integration to hiera working

  yumrepo { hiera('yumrepo::name') :
    metadata_expire => hiera('yumrepo::metadata_expire'),
    descr           => hiera('yumrepo::descr'),
    gpgcheck        => hiera('yumrepo::gpgcheck'),
    http_caching    => hiera('yumrepo::http_caching'),
    baseurl         => hiera('yumrepo::baseurl'),
    enabled         => hiera('yumrepo::enabled'),
  }

If I try to remove that definition and instead go for hiera_include('classes'), here's what I've got in the corresponding yaml backend

classes:
 - "yumrepo"

yumrepo::metadata_expire: 0
yumrepo::descr: "custom repository"
yumrepo::gpgcheck: 0
yumrepo::http_caching: none
yumrepo::baseurl: "http://myserver/custom-repo/$basearch"
yumrepo::enabled: 1

I get this error on an agent

Error 400 on SERVER: Could not find class yumrepo

I guess you can't get away from some sort of minimal node declaration w/ hiera and resource types? Maybe hiera_hash is the way to go?

I gave this a shot, but it produces a syntax error

  yumrepo { 'hnav-development':
    hiera_hash('yumrepo')
  }

I'm trying to determine what Puppet thinks the environment is on my agent nodes. Per the documentation I've configured the agent's environment in /etc/puppet/puppet.conf as such

[agent]
    environment = development

In order to view the environment I've found this code to add an environment fact to facter:

require 'puppet'

Facter.add("environment") do
  setcode do
    Puppet[:environment]
  end
end

However, on one of my agent nodes, if I run sudo facter -p environment, the result is production. I've tried to manually set the environment temporarily via sudo puppet agent --environment development, however the result from facter is the same.

Any idea what's going on?

I'm building RPMs with fpm. One of the goals is to set the user and group of the installed files, so I'm using the --rpmuser and --rpmgroup flags.

It's working for the most part, however one of the directories is not receiving the desired user/group. I've run fpm with the -e flag to inspect the Spec File. All the files and directories are marked beneath the %files directive that should set the desired user and group - adminuser,admingroup.

%files
%defattr(-,adminuser,admingroup,-)

# Reject config files already listed or parent directories, then prefix files
# with "/", then make sure paths with spaces are quoted. I hate rpm so much.
/etc/admin-services/admin.properties
/usr/share/admin-app/static/admin-console/index.html
/usr/share/admin-app/static/admin-console/console-env.js
/usr/share/admin-app/static/admin-console/css/styles.css
/usr/share/admin-app/webapps/admin-services.war

After installation, all the files belong to adminuser,admingroup except the /usr/share/admin-app/static directory (and everything beneath it), they all belong to root,root.

I don't think this is fpm's fault, the Spec File looks good. I believe this is an issue with rpmbuild under the hood. Any idea what could be going on?

I've read through the documentation on Spec Files, and I don't see any other directives that could be affecting the /usr/share/admin-app/static directory.

How would one get a --nogpgcheck option to yum via puppet? I've tried

package { 'unsigned-package':
  ensure          => latest,
  install_options => ['--nogpgcheck'],
}

and

package { 'unsigned-package':
  ensure          => latest,
  install_options => ['nogpgcheck'],
}

but looking at the output from an agent run, yum isn't getting that option.

As an aside (and maybe the reason it's not working for me), how do I verify my puppet has the install_options feature?

I'm running puppet 3.3.0-rc2.

I've created a custom repository following this guide.

Files are being served via http (nginx). I've cd'd into the directory to create the metadata with createrepo .. I can install a package through yum from my custom repo; so far, so good.

Now I want to see how an upgrade process might work, this is where I'm having trouble. My first package, that I installed successfully, is from build-utils-20130930-62.noarch.rpm

So I create a new package build-utils-20131001-63.noarch.rpm, then in the repo directory sudo createrepo --update .. Now I try sudo yum --nogpgcheck install build-utils, the result

Package build-utils-20130930-62.noarch already installed and latest version

I've tried to install the new version with a more explicit call to yum

sudo yum --nogpgcheck install build-utils-20131001-63

the result

No package build-utils-20131001-63 available.

Decided to dig into the filelists.xml file to see if the update worked, and sure enough

<package pkgid="c12eb685ebfedf4dd3155d0910517f3eb208dac09cc36b9e971541f038a4590d" name="build-utils" arch="noarch">
    <version epoch="0" ver="20131001" rel="63"/>

So I've even tried completely removing the current version

yum remove build-utils

Now I go to install from scratch

sudo yum --nogpgcheck install build-utils

yum offers me version 62 still! I've even tried to clear the yum cache su -c 'yum clean headers' to no avail.

How do I get my new versions available from the custom repository?

I'm trying to determine where to draw the line between what goes in puppet and what is part of an 'application'. One place I'm a bit perplexed is nginx conf.d files.

In apache, I'd have these files marked as .htaccess and thus, part of the application. However, in nginx there are no .htaccess files; they must go in the conf.d directory and the server bounced.

Fair enough, but when it comes to packaging the application and deploying server configuration with puppet I find the line between server configuration and application land rather blurry here.

If I put the files in the application package (we're using RPM), then I have server configuration in the application. However, if I put the files in puppet and the application author wishes to make a change (add another /location, or a rewrite etc..) then I have to update puppet and now the next version of the application depends on a puppet release.

Seems like a chicken and egg problem to me. Where is the most appropriate place to put these conf.d files then, puppet or application RPM?

I'd like to copy a number of files from puppet:// urls to a directory on an agent. I'm not sure if I'm doing something wrong here, but it seems like puppet doesn't like this

  file { '/etc/nginx/conf.d':
    path         => '/etc/nginx/conf.d',
    ensure       => directory,
    require      => File['/etc/nginx/nginx.conf'],
    source       => ['puppet:///modules/nginx/app1.conf',
                     'puppet:///modules/nginx/app2.conf'],
    sourceselect => all,
  }

Here's what I get when trying to run the agent

Error: Could not rename temporary file /etc/nginx/conf.d.puppettmp_9046 to /etc/nginx/conf.d: Is a directory

If I change things around a tiny bit by creating directories in the module, and pointing the resource at them it works

  mkdir module/files/app1 module/files/app2
  mv module/files/app1.conf module/files/app1
  mv module/files/app2.conf module/files/app2

new resource

  file { '/etc/nginx/conf.d':
    path         => '/etc/nginx/conf.d',
    ensure       => directory,
    require      => File['/etc/nginx/nginx.conf'],
    source       => ['puppet:///modules/nginx/app1',
                     'puppet:///modules/nginx/app2'],
    sourceselect => all,
    recurse      => true,
  }

It just seems a little silly to have to create directories to copy over a list of single files.

Edit

I tried adding a trailing slash on the path, but jumped the gun thinking this was the solution. The reason was I had my nginx class declaration commented out in the node definition. Trying it though I get the same error from above.

  file { '/etc/nginx/conf.d/':
    path         => '/etc/nginx/conf.d/',
    ensure       => directory,
    require      => File['/etc/nginx/nginx.conf'],
    source       => ['puppet:///modules/nginx/app1.conf',          
                     'puppet:///modules/nginx/app2.conf'],
    sourceselect => all,
  }

So I'm getting adjusted to the immutable variables in puppet, now looking for some advice, or clarification to whether I'm already on the right track.

I have a directory I'd like to sync, but potentially a number of subdirectories thereof. So I'd like to build up an array of one or more paths to pass to a recursive file resource. Ideally, I'd have something like this

$paths = ['fist/path'] # assume this is provided via class parameter
# this should work, since it's only overriding what was provided from higher scope
if($condition) {
  $paths += 'second/path'
}
# this won't fly, since $paths has already been set once locally
if($another_condition) {
  $paths += 'third/path'
}

but I can't do that, right, since the variables are immutable. What I've come up with as a 'best' approach so far is something like this

$paths = ['fist/path']
if($condition) {
  $condition_1_path = ['second/path']
} else {
  $condition_1_path = []
}
if($another_condition) {
  $condition_2_path = ['third/path']
} else {
  $condition_2_path = []
}

$paths = concat($paths, $condition_1_path, $condition_2_path)

I'm unsure if concat will omit an entry from the result if it's provided an empty array for one of its arguments, but waiting to test that once I figure out how to get stdlib loaded.

Either way, looking at this code, to me, it's plain hideous. Is there a cleaner way to do something like this?

I'm not much of a Ruby guy, but found how to list the Ruby load path. Here's what it looks like for me

$ ruby -e 'puts $:'
/usr/lib/ruby/site_ruby/1.8
/usr/lib64/ruby/site_ruby/1.8
/usr/lib64/ruby/site_ruby/1.8/x86_64-linux
/usr/lib/ruby/site_ruby
/usr/lib64/ruby/site_ruby
/usr/lib64/site_ruby/1.8
/usr/lib64/site_ruby/1.8/x86_64-linux
/usr/lib64/site_ruby
/usr/lib/ruby/1.8
/usr/lib64/ruby/1.8
/usr/lib64/ruby/1.8/x86_64-linux

Some of these directories don't even exist, and frankly, I'd think custom fact .rb files would be best placed in a Puppet-ish location, like /etc/puppet/facts or similar.

Should I go with one of the existing load path locations or create a new one for purposes of Puppet?

I'm new to RHEL. Trying to install software this morning and running into road blocks. Is it required to have a subscription to download packages via yum on RHEL?

I'm coming across different sources on the net, some make it sound like yes, you need a subscription, others making it sound like no, a subscription is only required for support.

In either case I'm stuck unable to install software ATM, because the machines I'm on don't have the subscription registered. Is there a way to install RHEL software without registering a subscription? If so, how?

I've just finished reading over this great thread explaining the different SSL formats.

Now I'm essentially looking for the opposite of How to split a PEM file

There's 4 files I want to consolidate, originally created for Apache, I'm looking at files specified by

• SSLCertificateFile
• SSLCertificateKeyFile
• SSLCertificateChainFile
• SSLCACertificateFile

What I'm mostly curious about is the order of the files in the consolidated dereivative, is that important? EG. if I were to just cat them together in the order they appear above, into a .pem, would it be valid, or should they be ordered a specific way?

FYI, I'm doing this for sake of using these certs as a combined single .pem in SimpleSAMLphp.

Does anybody know if the Project-based Matrix Authorization Strategy is supposed to work with LDAP integration?

There are several closed bug reports on JENKINS-2324 that say users don't need to have global read access and they can still get in to see a single project but that doesn't seem to be working with LDAP enabled, or maybe there's something else I'm doing wrong?

The first answer from restrict view of jobs per-user on Stack Overflow doesn't work for me with LDAP (you can read my post on the linked JENKINS-2324 above for more detail as well):

Short description without screenshots: Use Jenkins "Project-based Matrix Authorization Strategy" under "Manage Jenkins" => "Configure System". On the configuration page of each project, you now have "Enable project-based security". Now add each user you want to authorize.