in reply to CPAN 2.29 stuck with Net::SSLeahy
On Raspberry Pis, I personally like to use the system Perl and the system package manager to install Perl modules. This may not always give you the latest versions, but things install much faster because nothing needs to be compiled and tested. (Update: In other words, try sudo apt-get install libnet-ssleay-perl.)
It's also usually not recommended to use sudo cpan to install modules to the system Perl - use the system's package manager to install packages to the system Perl, or build your own copy of Perl (e.g. perlbrew) to install modules using a CPAN client there. Or, if using the system Perl, use something like local::lib to install modules to your home directory, so the system Perl's libraries are not affected.
On Raspberry Pis, one of the first things I do is sudo apt-get install build-essential cpanminus liblocal-lib-perl perl-doc and perl -Mlocal::lib >>~/.profile - see my notes on setting up RPis. (Update: I use local::lib on RPis for those few modules that aren't available in the package repositories or where the version in the system repositories is too old.)
If you still want to try installing Net::SSLeay yourself, you can also use the apt command to get most programs' build dependencies; in this case, try sudo apt-get build-dep libnet-ssleay-perl.
In general, I would recommend cpanm over the default CPAN client. Its --verbose option will show you the whole build process, giving you the exact error messages when stuff fails.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: CPAN 2.29 stuck with Net::SSLeay
by Aldebaran (Curate) on Mar 14, 2022 at 00:36 UTC | |
Thanks for your response, haukex. I'm not quite sure what you mean with reference to the "system package manager." I find no GUI equivalent of Ubuntu's "synaptic package manager." I prefer to get things done on the command line with *nix. (My windows preference is the opposite, but I prefer not to use Windows.) I wonder if you mean something like dpkg. As it is, I used sudo apt-get install libnet-ssleay-perl, and then I was unstuck. Would this be an instance of using the "system package manager," as you mean it? Update: After fighting with the same install on my droplet, I realize there were other headers that needed to be installed by the system:
The droplet had the former but not the latter, and it seems to make a difference. It's also usually not recommended to use sudo cpan to install modules to the system Perl - use the system's package manager to install packages to the system Perl, or build your own copy of Perl (e.g. perlbrew) to install modules using a CPAN client there. Or, if using the system Perl, use something like local::lib to install modules to your home directory, so the system Perl's libraries are not affected. On Raspberry Pis, one of the first things I do is sudo apt-get install build-essential cpanminus liblocal-lib-perl perl-doc and perl -Mlocal::lib >>~/.profile - see my notes on setting up RPis. (Update: I use local::lib on RPis for those few modules that aren't available in the package repositories or where the version in the system repositories is too old.)I think that's really solid advise for an rpi. I proceeded as you outline, forsaking sudo cpan, and with the addition of this command: cpanm --local-lib=~/perl5 local::lib && eval $(perl -I ~/perl5/lib/perl5/ -Mlocal::lib)cpanm has generally worked very well for my needs. I do have a sticky wicket, where I can't get cpanm to find dependencies:
I couldn't get cpanm to find modules in typical perl .pl scripts, so I herded the requires into a barebones module in its own directory. I don't know how to serve it up any better than that.(?) On Raspberry Pis, one of the first things I do is sudo apt-get install build-essential cpanminus liblocal-lib-perl perl-doc and perl -Mlocal::lib >>~/.profile - see my notes on setting up RPis. (Update: I use local::lib on RPis for those few modules that aren't available in the package repositories or where the version in the system repositories is too old.)Your link for setting up rpi's has proved very useful indeed, giving me much more on my plate to come up to speed on. I'm happy to report that I think I have my first fail2ban implementation:
Regarding section 5,
What is the purpose of doing this? Would this cause you to be indexed by search engines, or is it all within 50 yards (meters for bliako)?
Can you break this up into parts? I've used crontab once, so that syntax with all the asterisks is familiar. I read that socat -sruns it in sloppy mode, and I understand the syntax for sending stderr to the bitbucket. 2>/dev/nullI haven't cottoned onto it yet, even fiddling with udplisten.pl I have run:
, and was astonished to get somewhere in the debugger with it:
, with another terminal, doing: If you still want to try installing Net::SSLeay yourself, you can also use the apt command to get most programs' build dependencies; in this case, try sudo apt-get build-dep libnet-ssleay-perl.
I used this with my droplet in the cloud. In general, I would recommend cpanm over the default CPAN client. Its --verbose option will show you the whole build process, giving you the exact error messages when stuff fails.I sure like cpanm too when I finally get the thing kickstarted. cpanm Term::ReadKeyI always need to do this, too. Again, thanks for your comments. Gruss aus Amiland, | [reply] [d/l] [select] |
by haukex (Archbishop) on Mar 14, 2022 at 07:32 UTC | |
I'm not quite sure what you mean with reference to the "system package manager." I find no GUI equivalent of Ubuntu's "synaptic package manager." I prefer to get things done on the command line with *nix. ... I wonder if you mean something like dpkg. ... sudo apt-get install libnet-ssleay-perl ... Would this be an instance of using the "system package manager," as you mean it? The system package manager is the Advanced Package Tool on Debian-based systems like Ubuntu and Raspbian, and the RPM Package Manager on RedHat-based systems. Synaptic is just a frontend for APT and dpkg is one of the lower-level tools used by APT. Using APT from the commandline is done with the apt* commands, so yes, the apt-get command is what I meant. I personally often use the aptitude frontend for package management from the command line. I do have a sticky wicket, where I can't get cpanm to find dependencies: ... Configuring . failed. See /home/pi/.cpanm/work/1647208802.16932/build.log for details. You'd have to look into that file for the actual error message and let us know what it is. I might suspect a missing dependency on a lower level than Perl modules, e.g. a C library. I herded the requires into a barebones module in its own directory. I don't know how to serve it up any better than that.(?) Your requires1.pm would typically be called cpanfile and not start with a package statement. See cpanfile and the corresponding discussion in your thread Using Cartons to automate module installs. I couldn't get cpanm to find modules in typical perl .pl scripts You might be interested in lazy, though as the name implies, this shouldn't be your package management solution of choice. Regarding section 5, Crontab to broadcast RPi's address and name, What is the purpose of doing this? Would this cause you to be indexed by search engines, or is it all within 50 yards UDP broadcasts are usually not forwarded by routers, especially not to the Internet, so this should stay within the local network. On some (nowadays many) local networks, the router is smart enough to add a local DNS entry so the RPi can be reached by its hostname. On other networks, this may not be available, so there, this UDP broadcast simply serves for me to discover the IP that the RPi has been assigned. I broadcast the hostname so that I can keep multiple RPi apart (which is why it's a good idea to change the default hostname). Update: The background for this is that I prefer a headless setup of my RPis, purely over the network, which is why my notes include instructions on how to enable WiFi and the ssh server. There is a small security risk in not changing the password from the default before the first boot, perhaps I will update my notes in that regard. Update 2: Done. Also, BitBucket wasn't rendering some of the Markdown correctly, which should now be fixed, so those crontab lines you quoted should be readable on the site now (when in doubt, refer to the source). /Update Can you break this up into parts I'm basicially just sending the hostname in a UDP broadcast packet, where the socat commandline is what I looked up for that purpose, I'm not an socat expert :-) The crontab entries cause that to happen every minute, plus one extra time at boot, and I do 2>/dev/null so I don't get tons of emails from the cron daemon. | [reply] [d/l] [select] |
by Aldebaran (Curate) on Apr 21, 2022 at 01:18 UTC | |
I see. I've been trying to figure out everything that's going on with your udplisten.pl. I've made some changes primarily to introduce time measurement in a way that I could use for the higher-level abstractions of DateTime. Also, I couldn't understand where the newline after mypi was coming in, but I think that's what Data::Dumper gives the string in dumpstr. Regarding this syntax: my $FULLMSG = !!$opts{m};I searched for an operator !! in perlop, and not finding it have to believe it's a double application of !, essentially "Not-not". It seems to have the effect of making LHS the same as RHS, whether RHS is defined or not. That was torturous to say; do I have it right? Update: The background for this is that I prefer a headless setup of my RPis, purely over the network, which is why my notes include instructions on how to enable WiFi and the ssh server. There is a small security risk in not changing the password from the default before the first boot, perhaps I will update my notes in that regard. Update 2: Done. Also, BitBucket wasn't rendering some of the Markdown correctly, which should now be fixed, so those crontab lines you quoted should be readable on the site now (when in doubt, refer to the source). /UpdateThe revision in Markdown did help me make an effective crontab command with this as the result:
Source:
Slightly-redacted output:
so, everything's looking pretty good, but I wanted to complete step 4 in your rpi setup, with some attempt to understand it along the way: man rsyslogOn my first attempt, I just tacked it on the end:
, and restarted: sudo systemctl restart rsyslog, but rsyslog did not want to parse these lines:
, so I recalled that I didn't see any notation for a leading + or -, and went with this instead in /etc/rsyslog.conf:
, and that looks more like it, the parser having no objections. The man page for rsyslog had promised an html page, which I was enjoined to find. When running cat /var/log/syslogafter a successful start, this url was posted as output: www.rsyslog.com, where I finally learned what the r is for in rsyslog. (rocket-fast) So, yay, at the pace of a tortoise I think I've got task 4 covered. Thank you for your comments. Gruss aus Amiland, | [reply] [d/l] [select] |
by hippo (Bishop) on Apr 21, 2022 at 08:38 UTC | |
by Aldebaran (Curate) on Apr 02, 2022 at 23:40 UTC | |
Yes, indeed...thank you for the reminder, both then and now. I find myself refering back to previous write-ups when I'm facing the issues of breaking in a new system. A person tries to do the same things, but they are all a bit different. I've been able to get everything loaded except Plack::Handler::Twiggy. cpan shows that my version is undef, both before and after I reinstall:
I try to use cpanm to reinstall:
But the needle hasn't moved:
, and this consigns this command to failure:
So I'm still caught in the tentacles of Charybdis with this one module, looking for tips on how to get it installed properly. How do I get Plack::Handler::Twiggy to be version 0.1026 like Twiggy? Cheers, | [reply] [d/l] [select] |
by haukex (Archbishop) on Apr 03, 2022 at 06:34 UTC | |
by Aldebaran (Curate) on Apr 21, 2022 at 01:12 UTC | |
by Anonymous Monk on Apr 03, 2022 at 02:44 UTC | |
by Anonymous Monk on Apr 03, 2022 at 07:04 UTC |