Re: [Puppet Users] PuppetDB Issue with large array-valued fact

2016-04-19 Thread Wyatt Alt 



On 04/19/2016 10:39 AM, Mike Sharpton wrote:
 Again,*_thank you_* very much.  If I could buy you a beer, I would. 
 The machines in question are a mix of RHEL5/6/7.
Hah, you're very welcome. Thanks for confirming the OS; that means this 
isn't just a Solaris issue like that facter ticket suggests.


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5716FC3A.407%40puppet.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Hiera Error 400 on SERVER: Could not find data item classes in any Hiera data file and no default supplied

2016-04-19 Thread Ugo Bellavance 
Unfortunately, I wrote agen1 when I edited my post not to show internal 
info.

I tried your alternative solution (hiera_include('classes', [])) and it, 
well, allows the puppet command (puppet agent --noop --test --verbose by 
the way) to run OK instead of throwing a 400, but I don't see it applying 
ntp changes.

I'm actually testing a new server on 3.6.2 (EPEL), my production server is 
2.7 (EPEL).

Thanks a lot,

On Tuesday, April 19, 2016 at 4:39:21 PM UTC-4, Rob Nelson wrote:
>
> Ugo,
>
> In your last example you used 'agen1' instead of 'agent1'. Maybe it's just 
> a typo? Those are the best problems :) I also don't see where the 400 error 
> comes from, can you capture that somewhere?
>
> An alternative solution - or maybe complementary - is to change line 11 to 
> say `hiera_include('classes', [])`, or add a default class that notifies 
> "Can't find a class!" This way, all runs complete, even if they don't 
> manage the device properly, which ensures that facts are at least collected.
>
> I also recommend upgrading to the latest 3.x version now, and 4.x as soon 
> as you can, as SO MANY hiera bugs were fixed in 3.7/3.8 and then 4.3/4.4 
> that it's very likely that any bug you run into is already fixed by moving 
> past 3.6.2.
>
>
> Rob Nelson
> rnel...@gmail.com 
>
> On Tue, Apr 19, 2016 at 1:36 PM, Ugo Bellavance  > wrote:
>
>> Hi,
>>
>> I'm currently testing hiera and I can't make it work.  I get this 
>> error: Error 400 on SERVER: Could not find data item classes in any Hiera 
>> data file and no default supplied at /etc/puppet/manifests/site.pp:11 on 
>> node. I'm trying to do something like this: 
>> https://docs.puppet.com/hiera/3.0/complete_example.html (puppetlabs ntp 
>> module).
>>
>> Client: puppet 3.6.2
>>
>> On the master:
>>
>> puppet 3.6.2
>>
>> # puppet config print | grep hiera_
>> hiera_config = /etc/puppet/hiera.yaml
>>
>> Contents of /etc/puppet/hiera.yaml
>> ---
>> :backends:
>> #  - regex
>>   - yaml
>> :yaml:
>>   :datadir: /var/lib/hiera
>> #:regex:
>> #  :datadir: /var/lib/hiera
>> :hierarchy:
>>   - "host/%{fqdn}"
>>   - "domain/%{domain}"
>>   - "env/%{::environment}"
>>   - "os/%{operatingsystem}"
>>   - "osfamily/%{osfamily}"
>>   - "virtual/%{::virtual}"
>>   - common
>>
>> Contents of /etc/puppet/manifests/site.pp
>>
>> import "nodes/*"
>> import "os/*"
>> import "packages/*"
>> import "users/*"
>> import "service-types/*"
>>
>> # Enable hiera
>> hiera_include('classes')
>>
>> #filebitbucket { main: server => puppet }
>> #File { backup => main }
>>
>> # The filebucket option allows for file backups to the server
>> filebucket { main: server => 'puppet' }
>>
>> # Set global defaults - including backing up all files to the main 
>> filebucket and adds a global path
>> File { backup => main }
>>
>> Contents of the hiera file for this host:
>>
>> # cat /var/lib/hiera/host/agent1.example.com.yaml
>> ---
>> classes: ntp
>> ntp::restrict:
>>   -
>> ntp::autoupdate: false
>> ntp::enable: true
>> ntp::servers:
>>   - 0.ca.pool.ntp.org
>>   - 1.ca.pool.ntp.org
>>   - 2.ca.pool.ntp.org
>>   - 3.ca.pool.ntp.org
>>
>> Contents of the common file:
>>
>> # cat /var/lib/hiera/common.yaml
>> ---
>> ntp::autoupdate: true
>> ntp::enable: true
>> ntp::servers:
>>   - ntp1.example
>>   - ntp2.example.com
>>
>>
>> When debugging on the master:
>>
>> # puppet master --debug --compile agent1.example.com | grep hiera | grep 
>> -v Cannot | grep -v Looking
>> Warning: The use of 'import' is deprecated at 
>> /etc/puppet/manifests/site.pp:4. See 
>> http://links.puppetlabs.com/puppet-import-deprecation
>>(at grammar.ra:610:in `block in _reduce_190')
>> Debug: hiera(): Hiera YAML backend starting
>> Debug: hiera(): Found classes in host/agent1.example.com
>> Debug: hiera(): Found ntp::autoupdate in host/agent1.example.com
>> Debug: hiera(): Found ntp::restrict in host/agent1.example.com
>> Debug: hiera(): Found ntp::servers in host/agent1.example.com
>> Warning: Variable access via 'search_domain' is deprecated. Use 
>> '@search_domain' instead. 
>> template[/etc/puppet/modules/resolv/templates/resolv.conf.erb]:5
>>(at /etc/puppet/modules/resolv/templates/resolv.conf.erb:5:in `block 
>> in result')
>> Warning: Variable access via 'dns_servers' is deprecated. Use 
>> '@dns_servers' instead. 
>> template[/etc/puppet/modules/resolv/templates/resolv.conf.erb]:7
>>(at /etc/puppet/modules/resolv/templates/resolv.conf.erb:7:in `block 
>> in result')
>>
>> (I will eventually fix the warnings, I doubt they cause my hiera problem)
>>
>> hiera debugging on the master:
>>
>> # hiera ntp::servers clientcert=agen1.example.com --debug
>> DEBUG: 2016-04-19 13:26:43 -0400: Hiera YAML backend starting
>> DEBUG: 2016-04-19 13:26:43 -0400: Looking up ntp::servers in YAML backend
>> DEBUG: 2016-04-19 13:26:43 -0400: Looking for data source common
>> DEBUG: 2016-04-19 13:26:43 -0400: Found ntp::servers in common
>> ["ntp1.example.com", "ntp2.example.com"]
>>
>> (should not find the information in commo

[Puppet Users] Feedback on reporting verbose/debug/show_diff to syslog/eventlog (PUP-6125)

2016-04-19 Thread Michael Smith 
I'd like to solicit feedback on a ticket around changing some behavior in
logging when using --verbose, --debug, --test, etc.

PUP-6125  points out that
--logdest states
Where to send log messages. Choose between 'syslog' (the POSIX syslog service),
'eventlog' (the Windows Event Log), 'console', or the path to a log file.
If debugging or verbosity is enabled, this defaults to 'console'. Otherwise,
it defaults to 'syslog' on POSIX systems and 'eventlog' on Windows.

However, the actual behavior when setting debug or verbose is to enable
logging to the console, while also keeping the default behavior (or
whatever is specified in logdest).

The actual behavior seems to contradict the documented behavior. The actual
behavior also seems undesirable since debug, verbose, and show_diff
(implied by --test) can reveal secrets that might not be shown otherwise
during a run, and storing them to syslog/eventlog is more permanent and
more widely available than writing to the console.

Does anyone rely on the current behavior? For example, running puppet with
--verbose always enabled, and expecting that to go to syslog/eventlog?
Fixing PUP-6125 would require anyone using verbose (and other) flags in
normal operation to explicitly specify --logdest syslog/eventlog as well.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CABy1mMLGeQcTCBijnCLL1sSEiWoMQSBj15nG1N2keiEvAGASKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Hiera Error 400 on SERVER: Could not find data item classes in any Hiera data file and no default supplied

2016-04-19 Thread Rob Nelson 
Ugo,

In your last example you used 'agen1' instead of 'agent1'. Maybe it's just
a typo? Those are the best problems :) I also don't see where the 400 error
comes from, can you capture that somewhere?

An alternative solution - or maybe complementary - is to change line 11 to
say `hiera_include('classes', [])`, or add a default class that notifies
"Can't find a class!" This way, all runs complete, even if they don't
manage the device properly, which ensures that facts are at least collected.

I also recommend upgrading to the latest 3.x version now, and 4.x as soon
as you can, as SO MANY hiera bugs were fixed in 3.7/3.8 and then 4.3/4.4
that it's very likely that any bug you run into is already fixed by moving
past 3.6.2.


Rob Nelson
rnels...@gmail.com

On Tue, Apr 19, 2016 at 1:36 PM, Ugo Bellavance  wrote:

> Hi,
>
> I'm currently testing hiera and I can't make it work.  I get this
> error: Error 400 on SERVER: Could not find data item classes in any Hiera
> data file and no default supplied at /etc/puppet/manifests/site.pp:11 on
> node. I'm trying to do something like this:
> https://docs.puppet.com/hiera/3.0/complete_example.html (puppetlabs ntp
> module).
>
> Client: puppet 3.6.2
>
> On the master:
>
> puppet 3.6.2
>
> # puppet config print | grep hiera_
> hiera_config = /etc/puppet/hiera.yaml
>
> Contents of /etc/puppet/hiera.yaml
> ---
> :backends:
> #  - regex
>   - yaml
> :yaml:
>   :datadir: /var/lib/hiera
> #:regex:
> #  :datadir: /var/lib/hiera
> :hierarchy:
>   - "host/%{fqdn}"
>   - "domain/%{domain}"
>   - "env/%{::environment}"
>   - "os/%{operatingsystem}"
>   - "osfamily/%{osfamily}"
>   - "virtual/%{::virtual}"
>   - common
>
> Contents of /etc/puppet/manifests/site.pp
>
> import "nodes/*"
> import "os/*"
> import "packages/*"
> import "users/*"
> import "service-types/*"
>
> # Enable hiera
> hiera_include('classes')
>
> #filebitbucket { main: server => puppet }
> #File { backup => main }
>
> # The filebucket option allows for file backups to the server
> filebucket { main: server => 'puppet' }
>
> # Set global defaults - including backing up all files to the main
> filebucket and adds a global path
> File { backup => main }
>
> Contents of the hiera file for this host:
>
> # cat /var/lib/hiera/host/agent1.example.com.yaml
> ---
> classes: ntp
> ntp::restrict:
>   -
> ntp::autoupdate: false
> ntp::enable: true
> ntp::servers:
>   - 0.ca.pool.ntp.org
>   - 1.ca.pool.ntp.org
>   - 2.ca.pool.ntp.org
>   - 3.ca.pool.ntp.org
>
> Contents of the common file:
>
> # cat /var/lib/hiera/common.yaml
> ---
> ntp::autoupdate: true
> ntp::enable: true
> ntp::servers:
>   - ntp1.example
>   - ntp2.example.com
>
>
> When debugging on the master:
>
> # puppet master --debug --compile agent1.example.com | grep hiera | grep
> -v Cannot | grep -v Looking
> Warning: The use of 'import' is deprecated at
> /etc/puppet/manifests/site.pp:4. See
> http://links.puppetlabs.com/puppet-import-deprecation
>(at grammar.ra:610:in `block in _reduce_190')
> Debug: hiera(): Hiera YAML backend starting
> Debug: hiera(): Found classes in host/agent1.example.com
> Debug: hiera(): Found ntp::autoupdate in host/agent1.example.com
> Debug: hiera(): Found ntp::restrict in host/agent1.example.com
> Debug: hiera(): Found ntp::servers in host/agent1.example.com
> Warning: Variable access via 'search_domain' is deprecated. Use
> '@search_domain' instead.
> template[/etc/puppet/modules/resolv/templates/resolv.conf.erb]:5
>(at /etc/puppet/modules/resolv/templates/resolv.conf.erb:5:in `block in
> result')
> Warning: Variable access via 'dns_servers' is deprecated. Use
> '@dns_servers' instead.
> template[/etc/puppet/modules/resolv/templates/resolv.conf.erb]:7
>(at /etc/puppet/modules/resolv/templates/resolv.conf.erb:7:in `block in
> result')
>
> (I will eventually fix the warnings, I doubt they cause my hiera problem)
>
> hiera debugging on the master:
>
> # hiera ntp::servers clientcert=agen1.example.com --debug
> DEBUG: 2016-04-19 13:26:43 -0400: Hiera YAML backend starting
> DEBUG: 2016-04-19 13:26:43 -0400: Looking up ntp::servers in YAML backend
> DEBUG: 2016-04-19 13:26:43 -0400: Looking for data source common
> DEBUG: 2016-04-19 13:26:43 -0400: Found ntp::servers in common
> ["ntp1.example.com", "ntp2.example.com"]
>
> (should not find the information in common, should use the information in
> /var/lib/hiera/host/agent1.example.com.yaml
>
> Any help would be greatly appreciated.
>
> Thanks,
>
> Ugo
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/11548aff-32cd-4cdb-9886-4cfc079cd5fa%40googlegroups.com
> 
>

Re: [Puppet Users] Patterns for multi-arch libraries...

2016-04-19 Thread Ramin K 

On 4/19/16 9:06 AM, J.T. Conklin wrote:

Rob Nelson  writes:

Silly question, but what package manager doesn't let you upgrade those
two packages independently but also doesn't update the dependent
packages at the same time?


We have this problem on CentOS machines using the yum provider. The logs
reported something to the effect of openssl.x86_64 couldn't be updated
to version N+1 as that conflicted with openssl.i686 version N.  I wish
I had saved the logs at the time so I could share the exact text with
you all.

For a while - when it seemed like there was a new OpenSSL vulnerabilty
every other day - we had the openssl module's "version" parameter set to
"latest" in our hiera config.  When a new openssl version was available,
puppet would attempt and fail to install it each run. We'd manually have
to install the new version - so much for saving time. I'm hoping to find
a better option before the next time we need to update.

--jtc



Try adding install_options => 'update', to the package resource. Only 
works in Puppet 3+.


Ramin

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/57167AA4.6080104%40badapple.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Strategies for "boring" packages

2016-04-19 Thread Ramin K 

On 4/18/16 5:47 PM, J.T. Conklin wrote:

At work, we've written about 120 modules in our puppet code repository.
About two dozen are "interesting", in that they have lots of parameters
and configuration that is specific to our environment.  The balance are
"boring", rather they are mostly boilerplate with minimal configuration.
For example, our modules abstract the differences in package and service
names between RedHat and Debian based systems.

However, there is some disagreement amongst our puppeteers about how to
handle these "boring" modules. One side objects to the amount of boiler-
plate and duplication, and would prefer that we simply define packages
in our role/profile modules. The other side claims that abstracting
package and service names is value enough to justify the overhead, and
that "boring" packages often become "interesting" over time as new
requirements for flexibility and customization develop over time. Each
group is firmly convinced that their opinion is the right one.

So I throw the question to the puppet community... What strategies do
you use for "boring" modules so you're not overwhelmed by hundreds of
small boilerplate modules?

Thanks for sharing,

 --jtc



	At the previous job I preferred to promote packages to full modules 
from a holding module.


class vpackages {
  include vpackages::params

  @package { 'curl':tag => 'utils',}
  @package { 'htop':tag => 'utils',}
  @package { 'iftop':   tag => 'utils',}
  @package { 'whois':   tag => 'utils', name => 
$vpackages::params::whois, }


  # Mysql packages
  @package { 'percona-toolkit': tag => 'mysql', }
  @package { 'mysql-client':tag => 'mysql', name => 
$vpackages::params::mysqlclient, }

}

mysql-client is good example.

class mysql::install {
  package { 'mysql-server':
ensure => present,
name   => $mysql::params::packagename,
  }

  # realize packages like the client
  Package<| tag == 'mysql' |>
}

Later our Mysql installations were more complicated in several different 
roles with more versions. At that point it made sense to move 
mysqlclient into it's own parameterized module.


What I liked about the vpackages modules is that it's a visual 
representation of the shared namespace.


Ramin

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5716775B.7020007%40badapple.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PuppetDB Issue with large array-valued fact

2016-04-19 Thread Mike Sharpton 
Wyatt,

Thank you very much for your time and reply.  I greatly appreciate it.  I 
ran your query and your suspicions are correct.  Some DB servers lead the 
pack with a massive amount of data due to all the disk that is there.  We 
will probably just make these facts nil on all machines as we don't need 
them.  I would assume this will relieve the strain on PuppetDB and remove 
the resets/etc.  Again,* thank you* very much.  If I could buy you a beer, 
I would.  The machines in question are a mix of RHEL5/6/7.

Mike

On Tuesday, April 19, 2016 at 10:53:28 AM UTC-5, Wyatt Alt wrote:
>
> Hey Mike, 
>
> The unsatisfying answer is that PuppetDB handles giant facts 
> (particularly array-valued facts) pretty badly right now, and facter's 
> disks, partitions, and mountpoints facts can all get pretty huge in 
> cases such as SANs and similar. Can you try and see if the bulk of those 
> fact paths are coming from a small set of your nodes? I expect this 
> query might help: 
>
> https://gist.github.com/wkalt/4a58b9a97c79eee31971e5fc04dec0e4 
>
> You can mask the facts on a per-node basis by creating a custom fact 
> with value nil and weight 100 as described here: 
>
> https://docs.puppet.com/facter/3.1/custom_facts.html#fact-precedence 
>
> (this assumes you aren't using these facts for anything, but that sounds 
> like the case.) 
>
> Longer term, this is something we need to fix on our end. I created 
> https://tickets.puppetlabs.com/browse/PDB-2631 to track the issue. 
> https://tickets.puppetlabs.com/browse/FACT-1345 may also be related. 
>
> If you get those nodes tracked down, would you mind telling us the 
> operating system? 
>
> Wyatt 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/e09f34ec-fe6e-4d9a-9149-239e666f633c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Hiera Error 400 on SERVER: Could not find data item classes in any Hiera data file and no default supplied

2016-04-19 Thread Ugo Bellavance 
Hi,

I'm currently testing hiera and I can't make it work.  I get this 
error: Error 400 on SERVER: Could not find data item classes in any Hiera 
data file and no default supplied at /etc/puppet/manifests/site.pp:11 on 
node. I'm trying to do something like 
this: https://docs.puppet.com/hiera/3.0/complete_example.html (puppetlabs 
ntp module).

Client: puppet 3.6.2

On the master:

puppet 3.6.2

# puppet config print | grep hiera_
hiera_config = /etc/puppet/hiera.yaml

Contents of /etc/puppet/hiera.yaml
---
:backends:
#  - regex
  - yaml
:yaml:
  :datadir: /var/lib/hiera
#:regex:
#  :datadir: /var/lib/hiera
:hierarchy:
  - "host/%{fqdn}"
  - "domain/%{domain}"
  - "env/%{::environment}"
  - "os/%{operatingsystem}"
  - "osfamily/%{osfamily}"
  - "virtual/%{::virtual}"
  - common

Contents of /etc/puppet/manifests/site.pp

import "nodes/*"
import "os/*"
import "packages/*"
import "users/*"
import "service-types/*"

# Enable hiera
hiera_include('classes')

#filebitbucket { main: server => puppet }
#File { backup => main }

# The filebucket option allows for file backups to the server
filebucket { main: server => 'puppet' }

# Set global defaults - including backing up all files to the main 
filebucket and adds a global path
File { backup => main }

Contents of the hiera file for this host:

# cat /var/lib/hiera/host/agent1.example.com.yaml
---
classes: ntp
ntp::restrict:
  -
ntp::autoupdate: false
ntp::enable: true
ntp::servers:
  - 0.ca.pool.ntp.org
  - 1.ca.pool.ntp.org
  - 2.ca.pool.ntp.org
  - 3.ca.pool.ntp.org

Contents of the common file:

# cat /var/lib/hiera/common.yaml
---
ntp::autoupdate: true
ntp::enable: true
ntp::servers:
  - ntp1.example
  - ntp2.example.com


When debugging on the master:

# puppet master --debug --compile agent1.example.com | grep hiera | grep -v 
Cannot | grep -v Looking
Warning: The use of 'import' is deprecated at 
/etc/puppet/manifests/site.pp:4. See 
http://links.puppetlabs.com/puppet-import-deprecation
   (at grammar.ra:610:in `block in _reduce_190')
Debug: hiera(): Hiera YAML backend starting
Debug: hiera(): Found classes in host/agent1.example.com
Debug: hiera(): Found ntp::autoupdate in host/agent1.example.com
Debug: hiera(): Found ntp::restrict in host/agent1.example.com
Debug: hiera(): Found ntp::servers in host/agent1.example.com
Warning: Variable access via 'search_domain' is deprecated. Use 
'@search_domain' instead. 
template[/etc/puppet/modules/resolv/templates/resolv.conf.erb]:5
   (at /etc/puppet/modules/resolv/templates/resolv.conf.erb:5:in `block in 
result')
Warning: Variable access via 'dns_servers' is deprecated. Use 
'@dns_servers' instead. 
template[/etc/puppet/modules/resolv/templates/resolv.conf.erb]:7
   (at /etc/puppet/modules/resolv/templates/resolv.conf.erb:7:in `block in 
result')

(I will eventually fix the warnings, I doubt they cause my hiera problem)

hiera debugging on the master:

# hiera ntp::servers clientcert=agen1.example.com --debug
DEBUG: 2016-04-19 13:26:43 -0400: Hiera YAML backend starting
DEBUG: 2016-04-19 13:26:43 -0400: Looking up ntp::servers in YAML backend
DEBUG: 2016-04-19 13:26:43 -0400: Looking for data source common
DEBUG: 2016-04-19 13:26:43 -0400: Found ntp::servers in common
["ntp1.example.com", "ntp2.example.com"]

(should not find the information in common, should use the information in 
/var/lib/hiera/host/agent1.example.com.yaml

Any help would be greatly appreciated.

Thanks,

Ugo

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/11548aff-32cd-4cdb-9886-4cfc079cd5fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet on windows ignoring puppet.conf

2016-04-19 Thread Josh Cooper 
On Tue, Apr 19, 2016 at 7:56 AM, Mike Sharpton  wrote:

> Note sure if they changed the path with 1.4.1.  The path used to be what
> is below.  May want to try that.
>

Just to confirm, we haven't changed the location of where puppet.conf goes.


>
> C:\programdata\PuppetLabs\puppet\etc
>

Yep that's the one. Note C:\ProgramData is by default hidden.

Also you can ask puppet where it thinks its puppet.conf should be (so you
can be sure you're editing the same file that the agent will read):

C:\>puppet agent --configprint config
C:/ProgramData/PuppetLabs/puppet/etc/puppet.conf

Note if you are running puppet not elevated, it will attempt to use the
per-user location:

C:\>puppet agent --configprint config
C:/Users//.puppetlabs/etc/puppet/puppet.conf


>
> On Tuesday, April 19, 2016 at 9:38:20 AM UTC-5, Mattis Haase wrote:
>>
>> Hello,
>>
>> we have been using puppet for unix machines for quite a while and it
>> works fine.
>>
>> I have installed the latest puppet-agent (1.4.1) on Windows Server
>> 2012R2. The installation went fine and the communication between the
>> puppetmaster and the client works.
>>
>> However, it uses the production environment, ignoring the environment
>> setting in:
>>
>> c:\program files\puppet labs\puppet\etc\puppet.conf
>>
>>
>> It is worth noting that this folder did originally not exist. The folder
>> for the conf files was:
>>
>> c:\program files\puppet labs\puppet\puppet\conf
>>
>>
>> However, all documentation points torwards the first folder. I put the
>> same puppet conf into these three folders:
>>
>> c:\program files\puppet labs\puppet\puppet\conf
>> c:\program files\puppet labs\puppet\puppet\etc
>> c:\program files\puppet labs\puppet\etc
>>
>>
>> The contents of the file are this:
>>
>> # This file can be used to override the default puppet settings.
>> # See the following links for more details on what settings are available:
>> # -
>> https://docs.puppetlabs.com/puppet/latest/reference/config_important_settings.html
>> # -
>> https://docs.puppetlabs.com/puppet/latest/reference/config_about_settings.html
>> # -
>> https://docs.puppetlabs.com/puppet/latest/reference/config_file_main.html
>> # -
>> https://docs.puppetlabs.com/puppet/latest/reference/configuration.html
>> [main]
>> server=puppetmaster.develop.local
>> environment=develop
>>
>>
>> However, it still tries to pull from the production environment.
>>
>>
>> puppet.bat agent --configprint environment
>> production
>>
>>
>> I restarted the service, to no avail.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/51f8bdbc-875e-44a5-bbbf-4014e31b3ebc%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Josh Cooper
Developer, Puppet

PuppetConf 2016 , October 17-21, San Diego,
California
*Early Birds save $350*

-
Register by June 30th

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CA%2Bu97u%3DxXWoPtYf8-s3_60FkgO%2Bjo09DO%2BPXXNwaL2Z-fhkr3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Patterns for multi-arch libraries...

2016-04-19 Thread Rob Nelson 
That's weird, but I guess it kind of makes sense as they're independent.
Shame they have conflicts, though. It looks like, of all things, it's the
shared man pages causing the problem...
https://bugs.centos.org/view.php?id=5489

I assume you have both versions on purpose, but in case that wasn't the
intent, this article describes how to prevent non-systemarch packages from
getting through: https://access.redhat.com/solutions/158883


Rob Nelson
rnels...@gmail.com

On Tue, Apr 19, 2016 at 12:06 PM, J.T. Conklin 
wrote:

> Rob Nelson  writes:
> > Silly question, but what package manager doesn't let you upgrade those
> > two packages independently but also doesn't update the dependent
> > packages at the same time?
>
> We have this problem on CentOS machines using the yum provider. The logs
> reported something to the effect of openssl.x86_64 couldn't be updated
> to version N+1 as that conflicted with openssl.i686 version N.  I wish
> I had saved the logs at the time so I could share the exact text with
> you all.
>
> For a while - when it seemed like there was a new OpenSSL vulnerabilty
> every other day - we had the openssl module's "version" parameter set to
> "latest" in our hiera config.  When a new openssl version was available,
> puppet would attempt and fail to install it each run. We'd manually have
> to install the new version - so much for saving time. I'm hoping to find
> a better option before the next time we need to update.
>
>--jtc
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/877fftd1lq.fsf%40wopr.acorntoolworks.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAC76iT9%2BzCqi98D8_%3DkftjzTqwWf_OTinW5W0mB8WW%3DkvxLiHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Patterns for multi-arch libraries...

2016-04-19 Thread J.T. Conklin 
Rob Nelson  writes:
> Silly question, but what package manager doesn't let you upgrade those
> two packages independently but also doesn't update the dependent
> packages at the same time?

We have this problem on CentOS machines using the yum provider. The logs
reported something to the effect of openssl.x86_64 couldn't be updated
to version N+1 as that conflicted with openssl.i686 version N.  I wish
I had saved the logs at the time so I could share the exact text with
you all.

For a while - when it seemed like there was a new OpenSSL vulnerabilty
every other day - we had the openssl module's "version" parameter set to
"latest" in our hiera config.  When a new openssl version was available,
puppet would attempt and fail to install it each run. We'd manually have
to install the new version - so much for saving time. I'm hoping to find
a better option before the next time we need to update.

   --jtc

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/877fftd1lq.fsf%40wopr.acorntoolworks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PuppetDB Issue with large array-valued fact

2016-04-19 Thread Wyatt Alt 

Hey Mike,

The unsatisfying answer is that PuppetDB handles giant facts 
(particularly array-valued facts) pretty badly right now, and facter's 
disks, partitions, and mountpoints facts can all get pretty huge in 
cases such as SANs and similar. Can you try and see if the bulk of those 
fact paths are coming from a small set of your nodes? I expect this 
query might help:


https://gist.github.com/wkalt/4a58b9a97c79eee31971e5fc04dec0e4

You can mask the facts on a per-node basis by creating a custom fact 
with value nil and weight 100 as described here:


https://docs.puppet.com/facter/3.1/custom_facts.html#fact-precedence

(this assumes you aren't using these facts for anything, but that sounds 
like the case.)


Longer term, this is something we need to fix on our end. I created 
https://tickets.puppetlabs.com/browse/PDB-2631 to track the issue. 
https://tickets.puppetlabs.com/browse/FACT-1345 may also be related.


If you get those nodes tracked down, would you mind telling us the 
operating system?


Wyatt


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5716546A.9020400%40puppet.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Strategies for "boring" packages

2016-04-19 Thread J.T. Conklin 
Luke Bigum  writes:
> In my mind the "purest" way would be to go individual modules for each
> package/service combination. If the only requirement is that you are
> handling the differences between Red Hat and Debian flavours, then a
> module per package/service. These modules would be wholly self
> contained and rely on some of the standard set of Facter facts. And
> then you could publish them :-) It would also avoid future duplicate
> resource declarations where someone's embedded "packageX" into one
> profile, and it clashes with "packageX" in another profile.
>
> I can see the argument for putting package installs and service starts
> into a profile but only if it's global for every operating system. So
> if there was profile::webserver that needed Package[openssl] and that
> was correct for all operating systems, then fine. However if you have
> to start doing conditional logic to find the right name of
> Package[openssl] for Red Hat and Debian, then profile::webserver is
> not the place. profile::webserver is a container of business logic
> that relates wholly and only to your business and your team. The exact
> implementation of Package[openssl] has nothing to do with
> profile::webserver, as long as openssl gets there somehow, that should
> be all you care about at the Profile level. Implementing
> Package[openssl] really depends on the operating system Facts alone,
> and this should be in it's own module... and... all of a sudden your
> profile::webserver is operating system agnostic, which is cool.

I agree 100%.

> Question - why is it taking your team getting annoyed at generating
> boilerplate code? Surely you have some sort of "puppet module create"
> wrapper script or you use https://github.com/voxpupuli/modulesync? If
> you've got so much overhead adding boiler plate code for your boring
> modules then I think you're tackling the wrong problem... If you can
> bring the boiler plate code problem down to 1-2 minutes, it's got to
> only take another 5-10 minutes tops to refactor one package{} and one
> service{} resource out of the profile and into it's own module, and
> then your team argument kind of goes away.

Lately we've been creating a new module every 3-4 weeks. So it's been
faster to copy an existing module, run a perl script that renames the
module, packages, and services, than it would be to write/adapt a script
to generate new modules from a template + parameters. It only takes me a
minute or two to create a new module. The counter-argument is that it
only takes a few seconds to add a "package { 'foo': }" to a profile, and
that a module per package/service leads to a unmanagable set of hundreds
of modules.

While I'm in the camp that separate modules for each package/service are
a good thing, I started this thread in order to double check my opinion.

> Question - why are you writing 120 modules yourself? Are there really
> no other implementations of these things on the Forge or GitHub?

In some cases we've found existing modules, we even use a few.  But in
the general case, we've found it useful to write our own modules so they
have the same "look and feel" i.e. use the same sets of parameters and
facts with the same semantics. Our basic package/service boilerplate is
based off the example42 modules (at least as they were ~2-3 years ago).

   --jtc

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/87bn55d2bj.fsf%40wopr.acorntoolworks.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet on windows ignoring puppet.conf

2016-04-19 Thread Mike Sharpton 
Note sure if they changed the path with 1.4.1.  The path used to be what is 
below.  May want to try that.

C:\programdata\PuppetLabs\puppet\etc

On Tuesday, April 19, 2016 at 9:38:20 AM UTC-5, Mattis Haase wrote:
>
> Hello,
>
> we have been using puppet for unix machines for quite a while and it works 
> fine.
>
> I have installed the latest puppet-agent (1.4.1) on Windows Server 2012R2. 
> The installation went fine and the communication between the puppetmaster 
> and the client works.
>
> However, it uses the production environment, ignoring the environment 
> setting in:
>
> c:\program files\puppet labs\puppet\etc\puppet.conf
>
>
> It is worth noting that this folder did originally not exist. The folder 
> for the conf files was:
>
> c:\program files\puppet labs\puppet\puppet\conf
>
>
> However, all documentation points torwards the first folder. I put the 
> same puppet conf into these three folders:
>
> c:\program files\puppet labs\puppet\puppet\conf
> c:\program files\puppet labs\puppet\puppet\etc
> c:\program files\puppet labs\puppet\etc
>
>
> The contents of the file are this:
>
> # This file can be used to override the default puppet settings.
> # See the following links for more details on what settings are available:
> # - 
> https://docs.puppetlabs.com/puppet/latest/reference/config_important_settings.html
> # - 
> https://docs.puppetlabs.com/puppet/latest/reference/config_about_settings.html
> # - 
> https://docs.puppetlabs.com/puppet/latest/reference/config_file_main.html
> # - https://docs.puppetlabs.com/puppet/latest/reference/configuration.html
> [main]
> server=puppetmaster.develop.local
> environment=develop
>
>
> However, it still tries to pull from the production environment.
>  
>
> puppet.bat agent --configprint environment
> production
>
>
> I restarted the service, to no avail. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/51f8bdbc-875e-44a5-bbbf-4014e31b3ebc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] PuppetDB Issue with large array-valued fact

2016-04-19 Thread Mike Sharpton 
Hello all,

We are running Puppet 4.2.2 and PuppetDB 3.2.0 with around 2400 nodes and 
growing.  I am noticing some bad behavior with our PuppetDB, which is only 
going to get worse if what is below is correct.  I see the error below in 
the puppetdb log.

* ERROR [p.p.mq-listener] [cfe52545-29f8-4538-bf32-6ed41922be90] [replace 
facts] Retrying after attempt 8, due to: org.postgresql.util.PSQLException: 
This connection has been closed.*
*org.postgresql.util.PSQLException: This connection has been closed.*


I see this in the postgres log

*incomplete message from client*

and I can see the command queue jumping up after the connection has been 
reset for obvious reasons.  

I searched around and found this article.

https://groups.google.com/forum/#!topic/puppet-users/o_4K-UcuTQQ

I can see that this may be causing the issue I am seeing as we have several 
large array-valued structured facts. 


* count |name*
*---+*
* 26848 | partitions*
* 26014 | disks*
*  6141 | mountpoints*
*   494 | networking*
*   133 | processors*
*22 | os*
*15 | memory*
*14 | dmi*
*13 | ssh*
* 9 | dhcp_servers*
* 5 | system_uptime*
* 5 | identity*
* 4 | ruby*
* 4 | load_average*s



I can't get rid of these facts out of the box.  There doesn't seem to be 
anyway to filter facts, which is what it appears I need to do.  This fact 
also clutters PuppetBoard heavily.  Anyone ran into this issue before and 
found a way around it, or how to fix it?  Thanks in advance,

Mike




-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5e503d08-ee8b-426b-81a7-ae06e06b01c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet on windows ignoring puppet.conf

2016-04-19 Thread Mattis Haase 
Hello,

we have been using puppet for unix machines for quite a while and it works 
fine.

I have installed the latest puppet-agent (1.4.1) on Windows Server 2012R2. 
The installation went fine and the communication between the puppetmaster 
and the client works.

However, it uses the production environment, ignoring the environment 
setting in:

c:\program files\puppet labs\puppet\etc\puppet.conf


It is worth noting that this folder did originally not exist. The folder 
for the conf files was:

c:\program files\puppet labs\puppet\puppet\conf


However, all documentation points torwards the first folder. I put the same 
puppet conf into these three folders:

c:\program files\puppet labs\puppet\puppet\conf
c:\program files\puppet labs\puppet\puppet\etc
c:\program files\puppet labs\puppet\etc


The contents of the file are this:

# This file can be used to override the default puppet settings.
# See the following links for more details on what settings are available:
# - 
https://docs.puppetlabs.com/puppet/latest/reference/config_important_settings.html
# - 
https://docs.puppetlabs.com/puppet/latest/reference/config_about_settings.html
# - 
https://docs.puppetlabs.com/puppet/latest/reference/config_file_main.html
# - https://docs.puppetlabs.com/puppet/latest/reference/configuration.html
[main]
server=puppetmaster.develop.local
environment=develop


However, it still tries to pull from the production environment.
 

puppet.bat agent --configprint environment
production


I restarted the service, to no avail. 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d5550288-e96d-4990-a255-44ffd2eeb5f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppetdb garbage collection failing

2016-04-19 Thread Mike Sharpton 
Hello Wyatt, 

I think I have ran into an issue with large structured facts.  I posted a 
new message about it, but I was wondering if you have a solution for large 
partitions and disks facts?  I am not sure what to do as I cannot disable 
facts, and I have a large number of nodes.  Your help is appreciated. 
 Thanks,

Mike

On Monday, September 28, 2015 at 12:41:43 PM UTC-5, Wyatt Alt wrote:
>
> On 09/28/2015 05:40 AM, Matt Jarvis wrote:
>
> We seem to have hit a bit of an issue with puppetdb garbage collection. 
> Initial symptoms were exceptions in the puppetdb logs : 
>
> Retrying after attempt 6, due to: org.postgresql.util.PSQLException: This 
> connection has been closed.
>
>
> And on the postgres side :
>
>
> LOG:  incomplete message from client
>
>
> Having turned up the logging on postgres, it appears that the query 
>
>
> DELETE FROM fact_paths fp
>
>   WHERE fp.id in ( $some_ids )  AND NOT EXISTS (SELECT 1 FROM 
> facts f
>
>   WHERE f.fact_path_id in ( $some_more_ids ) AND 
> f.fact_path_id = fp.id
>
> AND f.factset_id <> $26355)
>
>
> is the cuplrit. This query is absolutely massive, with over 26000 id's 
> specified as parameters - as soon as the query is executed, postgres 
> returns incomplete message from client and drops the connection. 
>
>
> puppetdb is 2.3.7-1puppetlabs1
>
> postgres is 9.3
>
>
> Does anyone have any clues what's going on here ?
>
>
> Thanks
>
>
> Matt
>
> DataCentred Limited registered in England and Wales no. 05611763 -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users...@googlegroups.com .
> To view this discussion on the web visit 
> 
> https://groups.google.com/d/msgid/puppet-users/5fe3bad3-71a7-4348-a9ff-24d8a0284a1c%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
> Hey Matt,
>
> I can reproduce this by inserting a value at the beginning of an extremely 
> large array-valued structured fact, but we'll need to know more about your 
> particular data to confirm whether that's your particular issue. This could 
> be some large custom fact you're creating or something generated by a 
> module.
>
> I've created a ticket here around this issue here
> https://tickets.puppetlabs.com/browse/PDB-2003
>
> can you connect to the database via psql and share (either here or in the 
> ticket) the output of
>
> select count(*),name from fact_paths group by name order by count desc;
>
> ?
>
> My hope is that that will identify one or more large structured facts 
> associated with a lot of leaf values, and then we'll need to figure out 
> where they're coming from.
>
> Wyatt
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a8edf4e5-184f-455e-9547-e10aaea6f388%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Strategies for "boring" packages

2016-04-19 Thread Luke Bigum 
In my mind the "purest" way would be to go individual modules for each 
package/service combination. If the only requirement is that you are handling 
the differences between Red Hat and Debian flavours, then a module per 
package/service. These modules would be wholly self contained and rely on some 
of the standard set of Facter facts. And then you could publish them :-) It 
would also avoid future duplicate resource declarations where someone's 
embedded "packageX" into one profile, and it clashes with "packageX" in another 
profile.

I can see the argument for putting package installs and service starts into a 
profile but only if it's global for every operating system. So if there was 
profile::webserver that needed Package[openssl] and that was correct for all 
operating systems, then fine. However if you have to start doing conditional 
logic to find the right name of Package[openssl] for Red Hat and Debian, then 
profile::webserver is not the place. profile::webserver is a container of 
business logic that relates wholly and only to your business and your team. The 
exact implementation of Package[openssl] has nothing to do with 
profile::webserver, as long as openssl gets there somehow, that should be all 
you care about at the Profile level. Implementing Package[openssl] really 
depends on the operating system Facts alone, and this should be in it's own 
module... and... all of a sudden your profile::webserver is operating system 
agnostic, which is cool.

Question - why is it taking your team getting annoyed at generating boilerplate 
code? Surely you have some sort of "puppet module create" wrapper script or you 
use https://github.com/voxpupuli/modulesync? If you've got so much overhead 
adding boiler plate code for your boring modules then I think you're tackling 
the wrong problem... If you can bring the boiler plate code problem down to 1-2 
minutes, it's got to only take another 5-10 minutes tops to refactor one 
package{} and one service{} resource out of the profile and into it's own 
module, and then your team argument kind of goes away.

Question - why are you writing 120 modules yourself? Are there really no other 
implementations of these things on the Forge or GitHub?

--
Luke Bigum


- Original Message -
From: "J.T. Conklin" 
To: "puppet-users" 
Sent: Tuesday, 19 April, 2016 01:47:37
Subject: [Puppet Users] Strategies for "boring" packages

At work, we've written about 120 modules in our puppet code repository.
About two dozen are "interesting", in that they have lots of parameters
and configuration that is specific to our environment.  The balance are
"boring", rather they are mostly boilerplate with minimal configuration.
For example, our modules abstract the differences in package and service
names between RedHat and Debian based systems.

However, there is some disagreement amongst our puppeteers about how to
handle these "boring" modules. One side objects to the amount of boiler-
plate and duplication, and would prefer that we simply define packages
in our role/profile modules. The other side claims that abstracting
package and service names is value enough to justify the overhead, and
that "boring" packages often become "interesting" over time as new
requirements for flexibility and customization develop over time. Each
group is firmly convinced that their opinion is the right one.

So I throw the question to the puppet community... What strategies do
you use for "boring" modules so you're not overwhelmed by hundreds of
small boilerplate modules?

Thanks for sharing,

--jtc

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/87shyio252.fsf%40wopr.acorntoolworks.com.
For more options, visit https://groups.google.com/d/optout.
---

LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN
http://www.LMAX.com/

Recognised by the most prestigious business and technology awards
 
2016 Best Trading & Execution, HFM US Technology Awards
2016, 2015, 2014, 2013 Best FX Trading Venue - ECN/MTF, WSL Institutional 
Trading Awards

2015 Winner, Deloitte UK Technology Fast 50
2015, 2014, 2013, One of the UK's fastest growing technology firms, The Sunday 
Times Tech Track 100
2015 Winner, Deloitte EMEA Technology Fast 500
2015, 2014, 2013 Best Margin Sector Platform, Profit & Loss Readers' Choice 
Awards

---

FX and CFDs are leveraged products that can result in losses exceeding your 
deposit. They are not suitable for everyone so please ensure you fully 
understand the risks involved.

This message and its attachments are confidential, may not be disclosed or used 
by any person other than the addressee and are intended only for the named 
recipient(s). This message is not intended for any recipient(s) who ba