Profile Details

Toggle Sidebar
Loading cover... Drag cover to reposition
Recent updates
  • service fetchmail status - blank output - BUG ? - ClearOS 6.x

    On ClearOS 6.x - regardless whether fetchmail is running or not - the output is like this :-

    If we look at "/etc/rc.d/init.d/fetchmail" we see this for the status command

    No wonder there is no output - there is no command to do anything :-(
    changing it to this

    We then get

    or

    Surely this is a bug and not intentional ???

  • Tony Ellis
    Tony Ellis replied to a discussion, Badlock information hub

    Thanks Peter... 40 rpms all installed cleanly. As well as samba updates - updated apps, lvm2, device-mapper, kernel and other misc rpms.
    Also resolved a version conflict between i686 and x84-64 versions of libldb had lived with waiting for this update...

  • Since there have been no replies will take a stab at this which might give you something to research...

    1) Password Policies app installed with a very short maximum password age

    2) System compromised

    3) You don't say which ClearOS version you are running. On an earlier version a password would be revoked if there were too many failed logon attempts. This situation was often the result of intruders trying to login using a dictionary attack. Not sure if this is still the case...

    4) Check some of the other logs such as /var/log/audit/audit.log etc for activity at the times the passwords were reset.

  • Tony Ellis
    Tony Ellis's reply was accepted as an answer

    Re: What is the best way to load the ip_set module?

    Found a much more 'elegant' method to fix this that will survive rpm updates...
    Create a file as shown here and make executable

    This will be loaded by /etc/rc.d/rc.sysinit before iptables starts, as shown by this snippet from /var/log/messages

    Now if we look at this...

    What about all these other modules - do they require loading as well? loaded auto on demand? or ???
    Don't use ipset - so have no idea... I am using the latest kernel for ClearOS 6.8 beta i.e. 2.6.32-642.1.1.v6.i686

  • Found a much more 'elegant' method to fix this that will survive rpm updates...
    Create a file as shown here and make executable

    This will be loaded by /etc/rc.d/rc.sysinit before iptables starts, as shown by this snippet from /var/log/messages

    Now if we look at this...

    What about all these other modules - do they require loading as well? loaded auto on demand? or ???
    Don't use ipset - so have no idea... I am using the latest kernel for ClearOS 6.8 beta i.e. 2.6.32-642.1.1.v6.i686

  • Hi Nick - sorry, no idea how it is supposed to be loaded. Played around and it seems to be reluctant to load by the "normal" means...

    One way to load before the firewall that works, probably others... If you look in /etc/rc.d/rc3.d, for example, you will see S07ipset and S13firewall (at least on my system). This means that as it's a lower number, S07ipset will be loaded before S13firewall ('S' means start - 'K' kill or stop) assuming of course you are starting the ipset service at boot time (e.g. chkconfig ipset on). S07ipset is a symlink to /etc/init.d/ipset.

    Now if we edit /etc/init.d/ipset and add your little script, then every time ipset is started or restarted; then a check is made that the module is loaded.

    This works - after a fresh reboot found this...

    Naturally an rpm update to ipset could remove this. In these cases using chattr to set the immutable bit will result in a yum error if it tries to update that file and you are then alerted to what is happening...

    Bit of a hack - but at least it loads before the firewall....

  • Tony Ellis
    Tony Ellis replied to a discussion, COS 7.2 (kernel) issues

    Thanks John for the update. As suspected you were using the fake raid BIOS to provide the raid function. Having no first hand experience with fake raid (avoid it at all costs) not sure what your options are. Do the BIOS routines contain any code to check the integrity of the raid (i.e. the contents of each disk are identical) or other useful utilities? If the content of the two disks is identical - then the raid must be working, and my concern above is negated. I just do not know what to expect to see with fake raid.

    Alternatively, the dmraid program that should be installed in your ClearOS system may provide help. Dmraid is supposed to work with the fake raid BIOS in linux. I'm not familiar with it - use the man pages (man dmraid) to discover what options you have. "dmraid -r" might be a good starting place. There is also a "dmraid-events-logwatch" rpm that provides dmraid logwatch-based email reporting. Is this installed and working on your system? There may also be some good tutorials on the web for dmraid - I'll leave you to do the research. If your raid is working correctly and the integrity of the disks is established - then really don't have much in the way of suggestions to solve your initial problem. If the initial kernel loads OK then you can always use yum to remove the later kernels and try the latest one again.

    Not sure how familiar you are with software raid and mdadm. If you are; then saving your data, split the disks (i.e. break the raid1) and re-install as two separate disks and fresh install using mdadm software raid to create a raid1 is an option. This depends on your skill level and how comfortable you are with using software raid.

  • Tony Ellis
    Tony Ellis replied to a discussion, COS 7.2 (kernel) issues

    OK - it's gone midnight here and bed-time, but some initial thoughts - will look at this again tomorrow...

    1) Sil 3132 controller. That's a fake raid controller that uses firmware in the BIOS chip to produce software raid using your CPU, not real hardware on the card.

    2) Although you stated you were not - you are in fact using LVM - that is the default for ClearOS 7.x - even if you choose your own partitioning. Something that is not immediately obvious during the install and isn't really made clear.

    3) The listing of duplicates in the LVM command "pvdisplay" worries me. It almost looks like the initial install recognized the fake raid and installed on both disks as a raid1 mirror, but later sometime that broke and when the system now boots it sees the two disks as separate disks and using one physical disk only, and not as a raid1 mirror? If it was seeing a proper raid1 mirror surely should have only found and reported one disk - the raid1 mirror.

    How did you create the raid initially - using the routine in the raid controllers BIOS before you booted the install media?

  • Tony Ellis
    Tony Ellis replied to a discussion, COS 7.2 (kernel) issues

    John, You said you were using hardware raid. What raid controller is it? (make and model please)...
    If the raid is integrated with the motherboard - make and model of motherboard please...
    Looking to see if it is genuine hardware raid or fake-raid...

    Also can you let us know how the disk(s) are partitioned (cat /etc/fstab)
    and finally show the output of /usr/sbin/pvdisplay