While trying to run automated backups with syncbackfree some systems were having the subject error.
According to this forum the problem is with trying to use a mapped drive. I changed it to the LAN ip address
and we’ll see if that doesn’t resolve it.
While trying to install XML::RSS from CPAN on a CentOS installation with Perl 5.10, it kept failing on the pre-requisite XML::Parser
For example, one of the failures showed:
t/astress.t ……….. Failed 15/27 subtests
and concluded with
Test Summary Report
t/astress.t (Wstat: 0 Tests: 27 Failed: 15)
Failed tests: 5-11, 14, 18-24
Files=15, Tests=141, 1 wallclock secs ( 0.07 usr 0.03 sys + 0.88 cusr 0.14 csys = 1.12 CPU)
Failed 1/15 test programs. 15/141 subtests failed.
make: *** [test_dynamic] Error 255
/usr/bin/make test — NOT OK
//hint// to see the cpan-testers results for installing this module, try:
Running make install
make test had returned bad status, won’t install without force
To resolve this, I found the doc said
“You can install this module from OS package too, but CPAN has most fresh version.
so based on this I used
yum install perl-XML-Parser
to install the Perl XML Parser, and that then allowed
to finally complete the install correctly.
A process using curl (rtorrent) was giving the subject error after the remote system updated their secure cert from SHA1 to SHA256.
this page provides an answer; openssl needs to be updated: “It requires at least OpenSSL 0.9.8o for a total management of SHA256″
On top of that, (on Ubuntu jaunty) curl needed to be installed from source and the libcurl libraries were updated to get this working again.
In the local network, we have a samba share that doesn’t require a password. Most computers can access this share without any trouble. For some reason a new machine running Windows 7 Professional can’t access it without seeing a login box. Seems there are a lot of people who’ve had this or similar issues, and a lot of potential solutions.
Change made based on this page: In the Local Security Policy, Security Options, change “Network security: LAN Manager authentication level” (new setting: Send LM & NTLM – use NTLMv2 session security if negotiated)
Change made based on this page: In the Local Security Policy, Security Options, change “Microsoft network client: Digitally sign communications (always)” (new setting: Disabled)
Change made based on this page: In the Local Security Policy, Security Options, change “Network security: Minimum session security for NTLM SSP based (including secure RPC) clients” to “No minimum”
I tried a bunch of things including these above – one of them must’ve fixed it but the password box was still popping up; finally i entered ‘x’ as the username and ‘x’ as the password, miraculously it decided to let me in, whereas if I tried leaving it blank, it wouldn’t let me in. Possibly rebooting might have avoided that trouble? What a pain! But now I’m in, ahhhh.
After power failures, our MySQL slaves sometimes stop replicating. The error is:
Could not parse relay log event entry. The possible reasons are: the master’s binary log is corrupted (you can check this by running ‘mysqlbinlog’ on the binary log), the slave’s relay log is corrupted (you can check this by running ‘mysqlbinlog’ on the relay log), a network problem, or a bug in the master’s or slave’s MySQL code. If you want to check the master’s binary log or slave’s relay log, you will be able to know their names by issuing ‘SHOW SLAVE STATUS’ on this slave.
In the past, I would restore replication from another slave, but this method seems much better in that it’s faster and easier.
Get the Relay_Master_Log_File and Exec_Master_Log_Pos from “show slave status\G”;
reset slave to that point, and let it recover by itself as follows:
Be careful, using Relay_Master_Log_File value from “show slave status\G” for master_log_file, not Master_Log_File value. They’re the same in this case.
mysql> slave stop;
Query OK, 0 rows affected (0.00 sec)
mysql> change master to master_log_file=’LBMS-bin.000012′,master_log_pos=221245113;
Query OK, 0 rows affected (0.04 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
While trying to install openssl-1.0.0n and httpd-2.2.29, configure was giving an error like this:
checking for SSL_set_cert_store… no
configure: error: … Error, SSL/TLS libraries were missing or unusable
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install’. Stop.
Thanks to this page I was able to work it out, by prepending ‘export LDFLAGS=-ldl’ to the configure command.
This page also has some good discussion and possible answers.
I have a mail server on a LAN and other servers on the same LAN have trouble sending to local addresses because they resolve the mail server to the public ip address but then can’t get there. To fix this, I tried putting the mail server hostname and LAN ip into the /etc/hosts file, but frustratingly, postfix insists on not using the hosts file. I searched around and found the solution here
My config now is :
lmtp_host_lookup = native
#disable_dns_lookups = yes
ignore_mx_lookup_error = yes
This was difficult to find so I’m noting it here for future reference. To block all ports with fail2ban, change the jail file’s port value to “0:65535″
For example, here’s my SSH Jail file:
enabled = true
filter = sshd
action = iptables[name=SSH, port=”0:65535″, protocol=tcp]
sendmail-whois[name=SSH, firstname.lastname@example.org, email@example.com, sendername=”Fail2Ban”]
logpath = /var/log/secure
maxretry = 3
When converting a machine using the VMWare Standalone converter, I got the subject error. The process tries to find an ip address with DHCP but that’s not available on this network. The solution is to specify the ip address of the helper machine during the last step of the converter wizard.
On later versions of Ubuntu, the /var/log/messages is not on by default.
Since I use it for some applications, here are the steps I used to enable it:
Edit the file /etc/rsyslog.d/50-default.conf and uncomment the four lines:
(starts at line #38 on the current system I’m working on, Ubuntu 12.04)
Then restart syslog like this:
That’s it – /var/log/messages should now be there, just like the good old days!