Profile Details

Toggle Sidebar
Loading cover... Drag cover to reposition
Recent updates
  • Tony Ellis
    Tony Ellis replied to a discussion, ClearoOS and Webmin

    @Duncan - No, currently have no use for a PDC - in fact last time was back in the heyday of IBM's OS/2 Versions 3 and 4 :-)

    @Nick - actually have more than one DNS slave. Updating several machines with the same info would be a real PITA. With bind you update the master and the changes get promulgated automagically to the slaves... I suppose you could write a script to do something similar with dnsmasq - but prefer to use bind with syncing built in and all the other additional options. Used bind back in the OS/2 "WARP" server days from about 1994 - so quite familiar with it :-)

  • Tony Ellis
    Tony Ellis replied to a discussion, ClearoOS and Webmin

    Run bind here for one major reason - bind supports a master name server and slaves. All machines have the master as first DNS server and a slave as second DNS server. Thus can take down the master and not loose DNS on the other Servers and Clients. Don't use webmin to maintain the zone files. Also like the format of the zones files over the way dnsmasq organizes its data.

    Similarly run ISC dhcpd for handing out addresses - same reason. ISC dhcpd supports a primary and a secondary dhcpd server. Thus the primary can go down and secondary will hand out dhcpd addresses to clients. When the master comes back online they re-sync - same if the secondary goes down...

  • 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.