Filipe Brandenburger (filbr...@gmail.com)

Hi,

On Wed, Dec 17, 2008 at 01:45, Mad Unix <madunix@gmail.com> wrote:
> [root@intra.sdc:rescue]$yum update glibc
> ...
> Error: No Package Matching glibc.i686

I would say it's either a problem with your mirror, or with your local cache.

Try "yum clean all" followed by the same update again.

I tried it here (different mirror) and it worked for me:

$ sudo yum update glibc
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
* base: mirrors.portafixe.com
* updates: mirrors.portafixe.com
...
Setting up Update Process
Resolving Dependencies
--> Running transaction check
--> Processing Dependency: glibc = 2.5-24 for package: glibc-devel
--> Processing Dependency: glibc = 2.5-24 for package: glibc-devel
--> Processing Dependency: glibc = 2.5-24 for package: glibc-headers
---> Package glibc.i686 0:2.5-24.el5_2.2 set to be updated
--> Processing Dependency: glibc-common = 2.5-24.el5_2.2 for package: glibc
---> Package glibc.x86_64 0:2.5-24.el5_2.2 set to be updated
--> Running transaction check
---> Package glibc-devel.x86_64 0:2.5-24.el5_2.2 set to be updated
---> Package glibc-common.x86_64 0:2.5-24.el5_2.2 set to be updated
---> Package glibc-headers.x86_64 0:2.5-24.el5_2.2 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Updating:
 glibc                   x86_64     2.5-24.el5_2.2   updates           4.7 M
 glibc                   i686       2.5-24.el5_2.2   updates           5.2 M
 glibc-common            x86_64     2.5-24.el5_2.2   updates            16 M
Updating for dependencies:
 glibc-devel             x86_64     2.5-24.el5_2.2   updates           2.4 M
 glibc-headers           x86_64     2.5-24.el5_2.2   updates           601 k

Transaction Summary
=============================================================================
Install      0 Package(s)
Update       5 Package(s)
Remove       0 Package(s)

Total download size: 29 M
Is this ok [y/N]:



HTH,
Filipe

Hi,

On Tue, Dec 16, 2008 at 22:12, Spiro Harvey <spiro@knossos.net.nz> wrote:
> Just wondering if anyone can replicate this issue....
>
> if I try and access the help files direct (as root), such as ":help
> tutor" I get:
>
> If I press enter, it shows me what appears to be the output of a binary.

This is a bug long known to me (I never bothered to open a bug report
for it though).

"vim" has a plug-in to open compressed files, however in compatible
mode (which is the mode used when you call "vi" or if you don't have
the alias set) the plug-in is not loaded, so it cannot open the
helpfiles properly.

Never found a good workaround other than using "vim" explicitely.

Filipe

Hi,

On Tue, Dec 16, 2008 at 14:20, William L. Maltby
<CentOS4Bill@triad.rr.com> wrote:
> Since I know nothing of the scripts (python?)

Usually they're Bourne shell script.

You can see the scripts used by cups-libs with this command:
rpm -q --scripts cups-libs

> I thought I'd better seek some help.

Always a good call! :-)

>> One of the steps "ldconfig" does is creating symbolic links for
>> libraries, using the name that is hard-coded inside the library.
>
> AH! Ergo, when it tries and there is a real file, is sensibly doesn't
> replace it. And it's nice enough to let the user know.

That's it.

> Hmm. Wouldn't an rpm -q --whatprovides tell all occurrences? Of course,
> if the miscreant package was since removed it couldn't. Maybe rpm
> expects only one source per resource?

Probably the miscreant package was not an RPM, since otherwise you
would have a conflict and it wouldn't install "cleanly".

RPM can be used to show that something unexpected was changed with
your original RPM if you use this command:
rpm --verify lzo

> # ls -l `locate liblzo.so`
> -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1
> -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1.0.0

I would advise also doing "md5sum /usr/lib/liblzo.so.1*" to make
really sure they're the same.

As both files have the same date, I might be wrong in my suspicion
that that was the date the file replaced the symbolic link.

> It looks like the remove/ldconfig would be just as good here.

Yes!

> I'm going to check my logs and see if I can see what scrogged the setup.
> If I see anything likely, I'll post so others can see it.

Good, thanks!
Filipe

Hi,

On Tue, Dec 16, 2008 at 07:05, William L. Maltby
<CentOS4Bill@triad.rr.com> wrote:
> /sbin/ldconfig: /usr/lib/liblzo.so.1 is not a symbolic link

This message is not generated by "yum", but by "ldconfig" (as the
message itself is actually saying). When "yum" installs a new library,
the RPM contains instructions to run "ldconfig" after installing it,
so that the loader cache is updated and when you run a program that
needs that library it will be found.

One of the steps "ldconfig" does is creating symbolic links for
libraries, using the name that is hardcoded inside the library.

> $ rpm -q --whatprovides /usr/lib/liblzo.so.1
> lzo-1.08-5.el5.rf

The lzo package actually contains a file such as
/usr/lib/liblzo.so.1.0.0 (or similar version number), that file has
"liblzo.so.1" hard-coded as the name to look for inside it (it's the
SONAME), and the RPM also contains the symbolic link,
/usr/lib/liblzo.so.1 -> liblzo.so.1.0.0 (this is the symbolic link
created/updated by ldconfig).

However, in your system, you have a file and not a symbolic link:

> $ls -ld /usr/lib/liblzo.so.1
> -rwxr-xr-x 1 root root 406394 Nov 4 02:39 /usr/lib/liblzo.so.1

Something overwrote that symbolic link and created a file in that
place. Maybe by copying the original /usr/lib/liblzo.so.1.0.0 to
liblzo.so.1, or maybe by doing something else. I've seen this happen
with installation scripts for commercial products, maybe you installed
something that used "lzo" and included a version of it that was
packaged differently than the version you got from RPMforge.

The date of the file might be a clue on when that happened, in that
case, at 2:39am last Novemeber 4th. You can try to look for logs on
your system to see what might have done that.

In any case, the simple fix is to just remove that file (back it up
first, just in case), and run ldconfig again, you will see that the
symbolic link will be properly created.

You may also try to erase and reinstall the lzo RPM, I believe this
would also fix the problem.

HTH,
Filipe

Hi,

On Sun, Dec 14, 2008 at 21:25, Mike -- EMAIL IGNORED
<m_d_berger_1900@yahoo.com> wrote:
> Very interesting analysis. swatch uses tail -f, or something
> that mimics it to watch the file. I would then guess that as
> per your explanation, swatch contilues to watch the "old file".

Yes, actually using "tail -f" in a terminal while using "vi" to
rewrite the logfile in another terminal you can check that yourself.

You can also use "ls -li" to show the "inode number" of the file, you
will see that after saving the file with "vi" the inode will change,
which will mean that it's a new file.

Filipe

Hi,

On Sun, Dec 14, 2008 at 16:40, Kai Schaetzl <maillists@conactive.com> wrote:
> echo "1" > /proc/sys/kernel/sysrq
>
> To enable it. Maybe you can put it in one of the sysconfig files, somebody
> here will know :-)

To do this on boot, add this line to /etc/sysctl.conf:

kernel.sysrq = 1

If you change on the file, you can make it live on the system by
running "sysctl -p" (which will read /etc/sysctl.conf and do the
equivalent of "echo ... >/proc/sys/.../..." for each of the settings
in that file).

HTH,
Filipe

Hi,

On Sun, Dec 14, 2008 at 15:26, Mike -- EMAIL IGNORED
<m_d_berger_1900@yahoo.com> wrote:
> If I do a vi on the secure file and write it from vi, it stops recording.

Yes, that's the expected behaviour, because "vi" will actually write a
new file and rename it to /var/log/secure, so syslog will no longer be
writing to that file.

The file syslog is now writing to is not accessible on the filesystem
(unless you created a hardlink to it before), but other processes that
had it open before you saved it with "vi" will continue using the old
one.

> If I do a "/var/init.d/syslog restart", the secure file starts recording.

Yes, because syslog will open the new file again, by it's name, now
it's the file "vi" wrote. Actually, when you stop syslog (and all
other processes that had the old file open) it will be effectively
deleted, but not before that.

> I still have no idea how swatch continues to function after the syslog
> stops recording.

I'm not familiar with swatch, so I cannot say how it interacts with
files that are written/renamed as you described with "vi".

If it's a "daemon" that is running on background all the time, chances
are it will keep the file open (although not necessarily), so in this
case it will "see" the new entries from syslog. If it's run from cron
at fixed intervals, it will open the file every time it runs, so
chances are if you rewrite the file with "vi" it will no longer see
the new entries from syslog.

In any case, opening a logfile with "vi" is a bad idea, you should use
a more appropriate tool such as "less", or if you really want to use
"vi" commands, use "vi -R" or "view" for read-only mode.

HTH,
Filipe

Hi,

On Fri, Dec 12, 2008 at 18:28, Art Age Software <artagesw@gmail.com> wrote:
> IPTABLES -A INPUT -i bond0 -p tcp -m tcp -s 192.168.1.0/24 -d
> 192.168.1.0/24 --dport 11211 -m state --state NEW -j ACCEPT
>
> s1 kernel: DROP -- Catch All: IN=bond0 OUT= SRC=192.168.1.2
> DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=6467 DF PROTO=TCP
> SPT=51837 DPT=11211 WINDOW=202 RES=0x00 ACK FIN URGP=0

To use stateful rules, you must have rules for state ESTABLISHED too,
otherwise it will only allow the first packet and not the all others.
The first rule should always be:

iptables -A ... -i bond0 -m state --state ESTABLISHED,RELATED -j ACCEPT

That's the point of stateful rules, you match the rules further down
for new connections, but existing connections will always match the
first rule.

You should google for "iptables stateful" and try to get a better
explanation of what it is and how it works.

HTH,
Filipe

Hi,

On Fri, Dec 12, 2008 at 15:45, Art Age Software <artagesw@gmail.com> wrote:
> IPTABLES -A XXX -i bond0 -p tcp -m tcp -s 192.168.1.0/24 -d
> 192.168.1.0/24  --dport 11211  -j ACCEPT

> Dec 12 20:33:53 s1 kernel: DROP -- Catch All: IN= OUT=bond0
> SRC=192.168.1.1 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0
> DF PROTO=TCP SPT=11211 DPT=47567 WINDOW=0 RES=0x00 RST URGP=0

The packages it's dropping are with *source* port 11211, they are the replies.

Either configure your firewall in stateful mode (-m state, --state
NEW, --state ESTABLISHED, etc.) or add rules to allow the replies from
that source port.

HTH,
Filipe

Hi,

On Fri, Dec 12, 2008 at 09:13, Davide Cittaro
<davide.cittaro@ifom-ieo-campus.it> wrote:
> Ok, another one: the process I would like to start is not a daemon
> itself. If I start it with "daemon" function it remains in foreground.
> Ok, I can play with '&' but is there a init function to start in
> background a process?

Use "nohup" and redirect file descriptors to be safe.

nohup cmd... </dev/null >/dev/null 2>&1 &

Look up "man nohup" for (a few) more details.

HTH,
Filipe

Hi,

On Fri, Dec 12, 2008 at 11:10, Tony Mountifield
<tony@softins.clara.co.uk> wrote:
> From what I've been able to find, you can disable ASLR completely by
> putting the following line in /etc/sysctl.conf:
> kernel.randomize_va_space = 0

Thanks, I had just found that out, we tested it and indeed it works.

> Alternatively, you can run your program with ASLR disabled by using
> setarch to invoke it:
> setarch `uname -m` -R yourprog <yourprogoptions>

I didn't know about this one, sounds good. I'll have a good look at
"man setarch" and also try this out in the next couple of days.

Quick question: from "man setarch", the effect of using -R is "turns
on ADDR_NO_RANDOMIZE". Is it possible to use this flag
ADDR_NO_RANDOMIZE somewhere that will force that binary to use that
option always? I've read something about ELF headers, I wonder if that
is something that could be set there, and if it is, how do I change
the ELF headers to set it?

Thanks!
Filipe

Hi,

We are porting some applications from CentOS 4 to CentOS 5, the
applications use mmap, and we found out that they sometimes crash in
CentOS 5. We found out that this is due to the fact that CentOS 5 does
randomization of the address space when loading binaries, libraries,
and when using mmap, so that is what's causing our problem.

The thing is, I'm trying to google for it, but I did not find any
useful information on ASLR present in CentOS 5/RHEL 5/Linux 2.6.18. If
anyone has any good pointers on reliable information on what does that
code do, how to configure/tweak it, or how to use mmap properly to
work around the issues, I would really appreciate it. In particular,
if there is a switch/option that would allow us to disable it for some
binaries/libraries only, it would be great, since this could allow us
to do the upgrade sooner and try to find the proper fix for the
problem later.

Thanks!
Filipe

Hi,

On Tue, Dec 9, 2008 at 15:02, Dirk H. Schulz <dirk.schulz@kinzesberg.de> wrote:
> I have configured vsftpd with virtual users for webserver users (that
> means, a virtual users chrooted home is the document root of a virtual host
> in apache). That works fine so far - as long as SElinux ist not enforcing.

Look at "man ftpd_selinux".

HTH,
Filipe