cannot install version 0.3 artisaninweb - soap-client

Using laravel 5.4 I'm trying to use soapwrapper (artisaninweb) version 0.3, but always get an error:
Class 'Artisaninweb\SoapWrapper\Facades\SoapWrapper' not found
When installing version 0.2 everything works correctly.
What's wrong?

Try in your SoapController:
use Artisaninweb\SoapWrapper\SoapWrapper;
Or check in your config/app.php the aliases, it should be:
'aliases' => [
...
'SoapWrapper' => Artisaninweb\SoapWrapper\Facades\SoapWrapper::class,
...
],
Any time you change your app.php, you should run: composer dump-autoload.
I guess this last one was your use, let me know.

Related

puppetlabs-dhcp: Could not find dependency File[/etc/dhcp/dhcpd.conf]

I'm pretty new to puppet and I'm trying to use the module puppetlabs-dhcp (v0.3.0) with puppet master/agent v3.7.2. I'm using a very simple class declaration following the example given by the README file.
When I try to run the class on the node using puppet agent -t the run fails with the error
Error: Failed to apply catalog: Could not find dependency File[/etc/dhcp/dhcpd.conf] for Service[isc-dhcp-server] at /etc/puppet/modules/dhcp/manifests/init.pp:173
I tried adding a file resource before the dhcp class declaration but the file stays blank. None of the configurations are taken into account.
I checked the dependencies:
concat > 1.0.1 (using 2.0.2)
stdlib > 2.0.0 (using 4.13.1)
Here is the dhcp portion of the node in site.pp:
class {'dhcp':
dnsdomain => [
'jecks.lab',
'0.0.10.IN-ADDR.ARPA',],
nameservers => ['10.0.0.2'],
ntpservers => ['us.pool.ntp.org'],
interfaces => ['eth0','eth1'],
}
dhcp::pool{'ops.jecks.lab':
network => '10.0.0.0',
mask => '255.255.255.0',
range => ['10.0.0.100','10.0.0.254'],
gateway => '10.0.0.1',
}
dhcp::host {'debian-main':
mac => 'xxxxxxxxxxxxxx',
ip => '10.0.0.3',
}
What am I doing wrong? I assumed the dhcpd.conf file was created using concat from the parameters given in the class declaration.
This is a bug in puppetlabs-dhcp 0.3.0 when using concat 2.x that was fixed in 0.4.0. Using a newer version of the dhcp module or downgrading concat to 1.x would fix it.
Note that the puppetlabs-dhcp module moved to the Vox Pupuli community organisation a while ago, so you can find updates at puppet/dhcp on the Forge. The latest at the time of writing is 1.0.1, rather than 0.3.0.

Predicting package version

I'm configuring syslog-ng through puppet on my servers. The configuration files are very different between versions 2.x, 3.1 and 3.3 . On my hosts, depending on the operating system (centos5, centos6, debian 7, ubuntu), the available syslog-ng version will vary.
I had 2 ideas to adapt the configuration of syslog-ng to the correct version :
Custom Fact : It's easy to write a custom fact to test the installed version of syslog-ng. But this fact will be useless if syslog-ng is not already installed.
Conditions in the manifest : I find it a bit ugly to define a "case" in the manifest wich would determine the version of syslog-ng that the operatingsystem provides.
For me, the cleanest way to do this is to test which version of the package is available through the operatingsystem before installation.
A facter could do this, but I guess it would be a bit difficult.
Is there a puppetish way to solve my problem ?
There is indeed puppet-ish way to solve this problem!
You can combine $::osfamily with $::operatingsystemrelease to do something like this in your manifests:
case $::osfamily {
'CentOS': {
case $::operatingsystemrelease {
/^6/: { include syslog-ng::centos6 }
/^5/: { include syslog-ng::centos5 }
default: { notice("This operating system release for CentOs '${::operatingsystemrelease}' is not supported.")
}
}
default: { notice "Unsupported osfamily ${::osfamily}" }
}
I am not sure I understood all of your problem. In any case, one can use puppet package type to ensure a particular version and use $lsbdistdescription to get the OS name. For example :
package { 'syslog-ng' :
ensure => $::lsbdistdescription {
'/CentOS 7/': => "3.2",
'/CentOS 6/': => "3.1",
'/(Debian|Ubuntu)/' => "2.x",
default => "latest",
},
}
NOTE: In the above one has to get the exact name of the OS, i.e. CentOS 7 or CentOS 6 or Ubuntu from each OS. You can do that by executing facter --puppet | grep lsbdistdescription on the OS. I don't have variety of machines, so I couldn't check that exactly.
Then the configuration file can be just one sourced from a template. The template will vary based on the OS.
file { 'file.cfg' :
ensure => "present",
content => template("modulename/file.erb"),
require => Package["syslog-ng"],
}
Hope it helps.

Dependency cycle with apt source

I'm trying to install the puppet module at https://github.com/dwerder/puppet-mongodb
One of the requirements for it to work is to have the mongodb repository set-up. Since I'm trying to deploy it on Debian I tried using the following class to add the source:
class mongodb::apt::repo {
include apt
apt::source { '10gen':
location => 'http://downloads-distro.mongodb.org/repo/debian-sysvinit',
release => 'dist',
repos => '10gen',
key => '7F0CEB10',
key_server => 'keyserver.ubuntu.com',
include_src => false
}
}
However, upon trying to install the module (on a test node) I get the following output:
root#debian:/etc/puppet/modules# puppet agent --test
info: Caching catalog for debian.lan
info: Applying configuration version '1353946258'
err: Could not apply complete catalog: Found 1 dependency cycle:
(Exec[apt_update] => Class[Apt::Update] => Anchor[apt::source::10gen] => Anchor[apt::source::10gen] => Apt::Source[10gen] => Class[Mongodb::Apt::Repo] => Package[mongodb-10gen] => Anchor[mongodb::install::end] => Anchor[mongodb::install::end] => File[10gen.list] => Apt::Source[10gen])
Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz
notice: Finished catalog run in 0.06 seconds
The class is included in the module's install class at https://github.com/dwerder/puppet-mongodb/blob/master/manifests/install.pp
I'm not quite sure why this dependency cycle happens, any ideas?
What was your last change (that's probably the moment you added the cycle).
Try the suggestion to generate the graph. Post the generated dot file as gist so that we can investigate further.
Take a look at Debugging cycle or missing dependency.
Note that some dependencies are explicit (require, ->) or implicit (the resource provider add the dependency by it self)... having a look at the dot file should help.

Symfony2: Unrecognized options "method_access_control" under "jms_security_extra" error

So I'm trying to configure security access for some of my methods here, through JMSSecurityExtraBundle. I simply followed the instructions here : JMSSecurityBundle Doc.
I ended up having this in my config.yml file:
jms_security_extra:
secure_controllers: true
secure_all_services: false
method_access_control:
'MyBundle:.*:postEntityDelete': 'hasRole("ROLE_SUPER_ADMIN")'
Now I'm simply getting that error:
InvalidConfigurationException: Unrecognized options "method_access_control" under "jms_security_extra"
How can I have gone wrong on so little? Where's the catch and how do I solve this problem?
Thanks in advance!
Edit:
Deps :
[JMSSecurityExtraBundle]
git=https://github.com/schmittjoh/JMSSecurityExtraBundle.git
target=/bundles/JMS/SecurityExtraBundle
[metadata]
git=https://github.com/schmittjoh/metadata.git
version=1.1.0 ; <- make sure to get 1.1, not 1.0
[JMSAopBundle]
git=https://github.com/schmittjoh/JMSAopBundle.git
target=/bundles/JMS/AopBundle
[cg-library]
git=https://github.com/schmittjoh/cg-library.git
[JMSDiExtraBundle]
git=https://github.com/schmittjoh/JMSDiExtraBundle.git
target=/bundles/JMS/DiExtraBundle
Deps.lock:
symfony v2.0.13
twig v1.7.0
monolog 1.0.2
doctrine-common 2.1.4
doctrine-dbal 2.1.6
doctrine 2.1.6
swiftmailer v4.1.7
assetic v1.0.3
twig-extensions 446d870272cd87a720e95242eade38a2acf56eaa
metadata 1.0.0
SensioFrameworkExtraBundle cb61b92ed55241d93ed9726bc3f5f47c7d2ce8fe
JMSSecurityExtraBundle e752f888c51425f71382c056961f10f2be642102
SensioDistributionBundle 20b66a408084ad8752f98e50f10533f5245310bf
SensioGeneratorBundle b1ccb78c1743f30817b0fce9bb5c6baff6ed7bf8
AsseticBundle v1.0.1
What version of symfony and of the bundle are you using? The documentation you linked is following the master branch. There are links in the upper left to change versions. 1.0 doesn't seem to have that configuration option.
the deps file should contain:
[JMSSecurityExtraBundle]
git=http://github.com/schmittjoh/JMSSecurityExtraBundle.git
target=/bundles/JMS/SecurityExtraBundle
version=origin/master
You can also see here for someone else that had the same issue https://github.com/schmittjoh/JMSSecurityExtraBundle/issues/24

Griffon JMX Plugin 0.3 don't work.(update descript)

Griffon JMX Plugin 0.3 don't work.
anyone use this version
1.got error: no lib folder
then i download the src, cp lib/griffon-jmx-addon-0.3.jar
2.create a service
class SmsManagerService {
static expose = ['jmx:service=Country,type=special']
def serviceMethod() {
"a"
}
}
3.run-app && connect by jconsole, by did not find my mbean.
am i missing some step? plz help,thanks
Andres Almiray :
1 fixed in version 0.4 of the plugin
2 you are selection the wrong Java process. You must select the process that runs the application (griffon.swing.SwingApplication) not the one that runs the griffon command (o.c.g.GriffonMain).
3 JmxGriffonAddon and JmxGriffonPlugin are the only sources needed by the plugin

Resources