#theforeman

Hello. I've just get to know hammer-cli, which is a great tool. I'd like to know if there is a script that automates the export process?

Forgot to add, using foreman plugin.

Hi guys, I have just installed Foreman on ubuntu 16.04, but unfortunatly the reports doesn't work. I have try already to regenerate the certificats but the foreman-proxy doesn't recognize them anymore.

Here the error log => Puppet Report processor failed: Could not send report to Foreman at https://vm.foremanpuppet.local/api/reports: Could not generate DH keypair

Do you have any workaround about this?

Lud97: see https://tickets.puppetlabs.com/browse/SERVER-17 & the last comment where he specifies 'ssl_cipher'

jsherrill: how about making this a happy friday and releasing 3.3.2

ihre: thank you for your help, it's works now.

Hello, i want to understand my infra design for laying out capsules and master

Dj_: What questions do you have?

I have regions like Asia, EU, US .. and Asia has other small regions like Singapore, HK, India, Koria ... and UK has 2 DCs and US has 2 DCs

now how should i place master and capsules .. are there any criterias

i will have globally approx 6000 servers .. is 1 master sufficient ?

Capsules (Smart Proxies) can host content as well as run services like Puppet Master, which takes load off of the "master"

So the super basic answer is "yes, 1 master is sufficient - as long as your proxies run services that spread the load"

aitrus: do you have any testing data, how many capsules a master can handle ? over the WAN what could be latency ?

I don't have that data handy. The project may have some recommendations but I honestly haven't looked into them because in my scenario the guiding factor was isolation and reduced WAN traffic

But WAS still plays role while syncing contents right ?

There is also the question of what services you run on your capsules and what content you sync there (and your sync strategy)

I will sync RHEL repsmostly

repos*

and all capsules will run Puppet

master will not have puppet.

Are you familiar with the different sync options (on demand vs background/immediate)?

Download policies is a better term

Not much, i read about it, but what i understand is, they are mostly while doing first time setup or syncing content to satellite master from RHN.

how it affects capsule

i know on demand is good where it only syncs contents when client demands it, but not sure how capsules plays role

If Clinet connected to capsule demands some rpm ... satellite will download from RHN -> satellite then send to capsule -> client will get it ?

I believe the capsule follows the same policy. So when you sync from your master to a capsule it only sends metadata instead of all of the package content (until a client requests it)

So that will help with reducing WAN traffic during syncs

However, on demand does have some drawbacks

But then it will not slow down when client actually requests for rpm ?

For example, if the upstream is down you can't pull a package

But if you're using RHEL that risk is mitigated fairly well by their CDN (ignoring the recent outage, of course)

The first client to pull a package may experience some lag

on demand is also much more complicated internally, so there are more opportunities for bugs to creep up

So basically you have to decide what is more important - reduced resource usage or simplicity/stability

Do you know capsule <-> master syncs using http ? does qpid plays role in it ?

If you haven't already, here is some info to read: https://access.redhat.com/documentation/en-US/R...

yup i checked it.

And here are the capsule requirements: https://access.redhat.com/documentation/en-US/R...

And yes, qpid is a required port opening

(from capsule to satellite)

Thanks, btw do you know if we can setup some HA for satellite

if master goes down, will be difficult to recover.

I think that is still pending

If you are a Satellite customer the best way to get that escalated would be to open a support ticket so you are added to the BZ requesting the feature

I don't have the RH BZ in front of me. I recently swapped to a job that only uses the OSS versions of RH products

But I'm sure there is one because at my previous gig it was one of the first BZs I opened after Sat 6 was on our radar

Ok, infact CNAME is also not supported for this enterprise product

jsherrill: do you know if CNAME support will come ? for any large customer it will be the first requirement.

Dj_: here's some additional HA info: https://access.redhat.com/solutions/1251483

although not super helpful

i have seen other doc, for LB, using pacemaker, but that's complex and dont have subscriptions for pacemaker

has the 1.15 installed changed the expected value of foreman-foreman-url

in previous version I set the user to include http or https

with 1.15 it doesn't seem to be happy with it

or has how foreman::params::foreman_url gets set changed in some way ?

didn't this used to get set from hostname -f

it looks like it's being fed from lower_fqdn which is just a lowercase ::fqdn

facter fqdn shows a valid url

1.14 and 1.15 removed the --foreman-db-username and --foreman-db-password options from the installer, so how do you set the user/pass you want foreman to use ?