3dbc has asked for the wisdom of the Perl Monks concerning the following question:

Hi JAPH win32 masters,

Analyzed some perl's that are already installed on servers within the network, which already have the modules pre-installed within the embedded version. I was wondering if I can copy the perl modules file structure from the server and put them on my local machine without having to run dmake, cpan install or ppm at all?

I already wrote code that works in this environment, but need to transport it to my localmachine so I can put it on my task scheduler and automate these mundane ldap/sql extract csv reports ASAP

Sad to report I find myself with my hands cuffed behind my back and my shoe laces tied together, as one can imagine typing with my nose isn't fun. Don't have administrative rights on my local machine and this product bit9 is installed on my Windows7 localmachine. I've managed to get approval to have active state perl and komodo installed locally, but when I run a "cpan install Net::LDAP::LDIF" for example (even as administrator) it gets blocked by bit9 when running dmake. Working to have dmake whitelisted and was looking into using mklink /j on windows to make a junction to network share on c:\perl\site\lib\auto\dmake to a network path unless there's a simpler way.

Thanks Monks, you never disappoint!!
your knowledge sharing and support has always set me free!

Thank You!
- 3dbc
  • Comment on perl module install as non admin w/ bit9 blocking dmake

Replies are listed 'Best First'.
Re: perl module install as non admin w/ bit9 blocking dmake
by syphilis (Archbishop) on Jan 10, 2018 at 22:26 UTC
    but when I run a "cpan install Net::LDAP::LDIF" for example (even as administrator) it gets blocked by bit9 when running dmake

    Do you mean that bit9 prevents the module from even being built (in the "dmake" phase) ? ... or do you mean that bit9 prevents the module from being installed (in the "dmake install" phase) ?

    Assuming it's the latter, the first thing I would want to know is "into which directory is dmake trying to install the module ?"
    Running perl -V:installsitelib would normally tell you that. Does it report a directory to which you have "write" permissions ?

    UPDATE: As a double check, have a look at the INSTALLSITELIB entry in the generated Makefile. It should specify the same directory as perl -V:installsitelib

    Cheers,
    Rob
[reply]
[d/l]
[select]
Re: perl module install as non admin w/ bit9 blocking dmake
by marto (Cardinal) on Jan 11, 2018 at 10:14 UTC

    "I already wrote code that works in this environment, but need to transport it to my localmachine so I can put it on my task scheduler and automate these mundane ldap/sql extract csv reports ASAP"

    Have you considered just packaging your application using something like pp, copying that to your production systems?

[reply]
      pp looks cool will have to investigate that further, because on other systems they've been configured to use a local repository. Not sure if that was using pp, because perl was installed as part of CA Siteminder base install, which I'm leveraging and want to add additional modules to it with ppm or cpan using a local repository because there's no internet access on the servers and when I do a ppm rep list I can see the local repository but it points to a non existent path.

      What's interesting is on my local machine if I do a "ppm install xml::libxml" it works, but if I do "cpan install xml::libxml" it doesn't work and bit9 blocks it. Then again was working with the windows admin team who might have whitelisted it already because I was making a big stink about it. He came back and told me to use ppm instead of cpan

      Thanks again perl monks, you guys are always there to lend a helping hand and that's what makes perl great.
      - 3dbc
[reply]

        pp will let you package your script and dependencies, this is essentially a self extracting zip file.

        Regards Windows and security software, I've noticed pp struggle to build (via cpanm) because the tests do a lot of things very quickly. Exes pop into creation, get run and deleted within a very short space of time. The last time I had to install this one test failed, on investigation this was the very reason so I just installed the module.

        You may already know but, the distinction between using PPM vs cpanm/cpan is that ppm will download, unpack and copy something into the required places, where as the other methods will download, unpack, build (in some cases using the C compiler), test then install the module. It's a way more involved process in terms of what goes on under the hood, but from my experience more reliable in terms of ongoing support (ppm requires a commercial support licence after some time IIRC), and in terms of actually getting the packages you need.

[reply]

Back to Seekers of Perl Wisdom