It might happen because curl can't access valid CA certs bundle. Maybe you just didn't install those, so try this:
apt-get install ca-certificates
If it doesn't help - check CURL_CA_BUNDLE, make sure curl doesn't look for bundle in a wrong place.
Get the patch for lenny from http://pastebin.com/Hhsut197 (based on the official glibc patch, removed ChangeLog, NEWS stuff, adapted Makefile for lenny, removed patch #2 for getXXbyYY_r.c)
Run: apt-get update && apt-get source libc6; apt-get build-dep libc6
Copy your patch in glibc-2.7/debian/patches/all
Add the patch name in ...
Run this command
apt-get install rcconf
Once installed, run rcconf in SSH and you will receive a dialog box displaying all services set to run on boot. Select the ones by pressing Space to disable/enable the particular and you're done, simpley click on Ok and that service wont bother to start again on next boot. Being using this for years. Very handy tool ...
You need to give more information about your server configuration, and post those logs. How do you know that the load average got high ?
The "load average skyrocketing to over 100 before failure" symptom can have many causes, but there are frequent ones.
First, what is the load average ?
I recommend looking at this post to get more information on the ...
When creating a PV on a device, the LVM label sits (by default) in the second 512B sector. If the device is a whole disk on which grub is to be installed, then this is exactly where grub's core.img sits. The LVM metadata, for which there is by default one copy per disk, sits after the label, starting in the fifth sector. (An optional second copy of the ...
You can also use the eglibc patch from Squeeze LTS to build patched Lenny packages:
Put it in glibc-2.7/debian/patches/any and add it to the end of the glibc-2.7/debian/patches/series file. Now build the packages, upgrade your system with them and test ...
To properly daemonize a process for Debian you will need to take several steps including forking away from the controlling process, resetting IO, and creating a process id file to play nice. You can instead use something like the daemon program from the package of the same name to do that for you. If that is what you wanted to do, the answer can be found ...
Well, problem solved:
I was running an etch-as-testing, apparently.
set the apt sources.list to point to etch on archives.debian.org .
had to manually get and install etch's libc6-dev_2.3.6.ds1-13etch10+b1 from archives.debian.org , forcing the version down apt-get's throat.
dist-upgraded a couple of times.
set the apt sources.list to point to lenny on ...
Yes the problem you are experiencing is called deprecation. Lenny is no longer supported by Debian (for a year now I think) so it can't find the files in the repositories simply because they do not exist anymore. Your only chance is to upgrade your machine to the next stable version, which is "Squeeze".
There are various reasons where such "duplicates" may occur:
your data is toast.
an application INSERTed using the auto-increment, but later ran an UPDATE to
manually modify the identity to a different, probably existing value. This
sometimes occurs with application developers who are sorting "by ID" and want
to "fix the sorting" (by actually breaking ...
I would follow Debian guidelines for upgrading: this means upgrade your base system first, then the rest; if I were you I would let Debian choose which package upgrade first.
In case you would to update manually each of your "relevant" packages, I would follow this order: mysql, java, tomcat.
Remember you'll probably switch from sun-jdk6 to openjdk7, if I ...
If possible at all, you should definitely use Reza's answer and use the 'upload' module.
However, if you use nginx as a reverse proxy with a backend on a different machine, that module won't necessarily do much for you. To choose where your temporary request bodies (including uploaded files) go, use the
client_body_temp_path config option.
Your server was compromised (as per previous question and also confirmed somehow with the strange behaviour of binaries like tail or others that were replaced).
So you have to do a clean re-install of everything; no commands can be trusted and they may not work properly as it seems to be happening. You should use a new server and install Linux and the rest ...
I've recompiled the glibc-2.7 sources for Debian Lenny including the CVE-2015-0235 patch of Debian Squeeze LTS.
As it takes quite some time to compile these packages you may grab a copy via https://flo.sh/debian-lenny-cve-2015-0235-glibc-patch/
Vulnerability check looks ok, now:
[00:15:26] root@[...]: /usr/src/ghost> ./ghost
Thank you guys ...
With Gitlab, You can clone via HTTP or via SSH. Which URL do you use ?
via HTTP(S), you must provide the login/password from your GitLab UI account.
via SSH, you must configure correctly SSH on your client : first try to keep your private key (corresponding to the public key configured in your GitLab account) at the default place where SSH will search for ...
A few issues I see. You say you did this:
sudo service mysql restart
But are you logged in as root or a superuser?
Also, This error makes 100% no sense:
invalid option -- n
Try `tail --help' for more information.
tail: invalid option -- n
Try `tail --help' for more information.
So are you trying to tail the MySQL log? And perhaps entered ...
If you have a rootkit on the machine (the most damaging virus), it will most likely have inserted code into your kernel modules (so it can hide itself when using normal detection tools like md5sum or netstat), and to libraries (so that other tools installed other than normal detective ones will similarly be nobbled).
There are a number of tools which are ...
So the real answer is this:
The servers that where on squeeze where by a different provider then the lenny ones. As I found out the squeeze ones where compiled with a kernel that included the grsecurity patch which restricts access to /proc to just the that user's processes.
You can add grsecurity as a patch to other linux distributions following this ...
So I came across this issue after one of our replication servers went into an inconsistent state. We couldn't get it back on line with a quick fix and decided to reinitialize the replication with a new backup.
The question stated above is not the same problem but does return the same error therefore I decided to add this answer in case other people ...
First thing, check to see whether the rows in question exist in that state in the original database.
Chances are, what happened is one of the following:
The column/field in question wasn't unique at one point, but was altered later on.
This is a slave database that you are dumping, and there have been some binlog replays at some point, and potential ...
Use the following /etc/apt/sources.list:
deb http://archive.debian.org/debian lenny main non-free contrib
deb-src http://archive.debian.org/debian lenny main non-free contrib
Then do everything you can to get this system upgraded as soon as possible. :)
Per Gabor Vincze, the script from Ubuntu forums seems to do a decent code:
# This script will change all entries of the form /dev/sd* in /etc/fstab to their appropriate UUID names
# You must have root privelages to run this script (use sudo)
if [ `id -u` -ne 0 ]; then # Checks to see if script is run ...
Lucas is right; if for some reason [and let it be a good one because you should not do it on any internet-reachable server] you have to stick to lenny - edit your /etc/apt/sources.list and change http://some.mirror/ to http://archive.debian.org/ ; run apt-get update and install what you need.
as a workaround you can prevent a package upgrade by setting it to "hold" in dpkg:
echo "grub-common hold"|dpkg --set-selections
then you can revert this with
echo "grub-common install"|dpkg --set-selections
another option mentioned here: http://lists.debian.org/debian-user/2009/07/msg00477.html
Pin: release a=fakerepo
In my case all the permissions were correct and I even did a restorecon on the directory, but it would only work when selinux was permissive or disabled.
The solution I found from bugzilla 545128 was
setsebool -P named_write_master_zones=1
You are trying to use SMB 1.0, which may very well be disabled by default now.
Can you use ver=3.0, which specifies SMB version 3.0.
You really should just ask your SMB admins what the minimum requirements are, as they may well have been elevated.
What is the version of the SMB server you are talking to?