I have a script that uses Net::SSH:Perl module. It is able to ssh to RHEL6.9 hosts but not RHEL7.4 hosts. I get the following error:
Protocol error: expected packet type 91, got 80 at /Net/SSH/Perl/Packet.pm line 221
How do I remedy this?
A simple search for the error message gives this post from 2016 and this bug report from 2016 which both indicate that the issue was fixed in version 2.01 of the module, released in 10/2016. Thus, you are probably using an older version and need to upgrade.
Related
I have a script created to automate the process of generating Let's Encrypt certificates for my websites.
The Script always worked fine, but starting yesterday I am receiving the issue below when I try to run:
New-ACMERegistration -Contacts mailto:user#email.com -AcceptTos
Error:
System.UriFormatException: Invalid URI: The URI scheme is not valid.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at ACMESharp.AcmeClient.GetDirectory(Boolean saveRelative) in
C:\projects\acmesharp\ACMESharp\ACMESharp\AcmeClient.cs:line 145
at ACMESharp.POSH.NewRegistration.ProcessRecord() in
C:\projects\acmesharp\ACMESharp\ACMESharp.POSH\NewRegistration.cs:line 63
at System.Management.Automation.CommandProcessor.ProcessRecord()
I have the latest version of th PowerShell module installed (https://www.powershellgallery.com/packages/ACMESharp/0.9.1.326).
Has anybody stumbled on a similar issue?
An error is thrown because the BaseUri: https://acme-v01.api.letsencrypt.org/directory returns a JSON Error. ACME Protocol Version 1 has been deprecated. You will need to use a client that uses ACME Protocol Version 2.
Consider replacing ACMESharp with ACME-PS.
I've installed bugzilla in my local machine (Windows 7) and its working good. But when I try to create a new account it says:
Traceback:
at Bugzilla/Mailer.pm line 179.
Bugzilla::Mailer::MessageToMTA(...) called at Bugzilla/Token.pm line 89
Bugzilla::Token::issue_new_user_account_token(...) called at Bugzilla/User.pm line 2423
Bugzilla::User::check_and_send_account_creation_confirmation(...) called at C:/bugzilla/createaccount.cgi line 39
I followed the documentation provided in bugzilla. But unable to resolve this issue. Can anyone help this?
I got a connection test script that is run on my client system and is calling a Perl DBI Proxy server via
my $dbh = DBI->connect("dbi:Proxy:$dbiproxy;dsn=$dsn", "$user","$pass",{ PrintError => 1}) || ($errmsg = "ERROR on connect");
When running the script it will fail stating
connect('hostname=***;port=2001;dsn=dbi:Oracle:***','***',...) failed: Cannot log in to DBI::ProxyServer: Unexpected EOF from server at /usr/local/share/perl/5.10.1/RPC/PlClient.pm line 79.
The log on the DBI Proxy server reads
Wed Dec 15 14:47:47 2015 err, Child died: Storable binary image v2.7 more recent than I am (v2.6) at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 363, at /usr/lib/perl5/site_perl/5.8.0/RPC/PlServer/Comm.pm line 179
So I checked the Perl and Storable module version numbers of the two systems and the DBI proxy server seems to be rather outdated:
source: perl 5.10.1, storable 2.20, storable 2.7 (binary), Debian 6.0
target: perl 5.8.0 , storable 2.13, storable 2.6 (binary), RHEL 3
The problem is that I can not update the module/perl version of the target system, so I thought I could simply lower the utilized client version by modifying the /usr/local/share/perl/5.10.1/RPC/PlServer/Comm.pm file and change the line
require Storable;
to
use Storable 2.13;
but this will result in the same error as above. I also tried to use Storable 2.13 directly in my Perl test-script, but that does not change anything, either.
When googling this I could not find any solution, only confirmation that this version discrepancy can be a problem. Increasing the DBI_TRACE level on the client side also did not reveal anything new. Frankly I don't know what to try next and any help would be greatly appreciated.
I'm trying to implement Kamailio 4.1 with Asterisk 12.1.0 regarging this tutorial:
http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb
And when I try to compile kamaili.cfg, I still got this error:
Apr 19 16:59:31 debian /usr/local/sbin/kamailio[5751]: ERROR: <core> [route.c:1137]: fix_actions(): route "FROMASTERISK" not found at /usr/local/etc/kamailio/kamailio.cfg:780
I have loaded all modules like in tutorial.
I tried to find some solve this issue, but with no result.
Thank you for help!
That error mean in your kamailio.cfg file not found section with route "FROMASTERISK"
Also note, that your kamailio config file is /usr/local/etc/kamailio/kamailio.cfg
You have add section or remove route.
We had to restart a server that has a TYPO3 site on it. We made no changes to the database of any of the TYPO3 files themselves, just a standard restart. The issue is that now the server is spewing php errors. I would like to stress that no server configuration changes were made.
A sample of our error logs:
[Wed Jun 27 23:55:19 2012] [error] [client ****************] PHP Strict Standards:
Declaration of tx_commerce_db_article::get_attributes() should be compatible with tx_commerce_db_alib::get_attributes($uid, $attribute_corelation_type_list = '')
in /var/www/html/***********/class.tx_commerce_db_article.php on line 63
Anyone have any ideas of what might have cause typ03 to make a deposit on the living room rug?
The server will take the request but admin page and main page will not display.
Someone updated PHP to version 5.4 on the server. Only the latest dev versions in the git repositories include a fix to the display error pattern that explicitly excludes E_STRICT.
Have a look at this issue and the according patches:
http://forge.typo3.org/issues/35154