1. Store
  2. Apps
  3. Hardware
  4. Support
  5. Solutions

ClearFoundation

About Me

Basic Information

About me
BOFH
Working on the west coast of Vancouver Island

Whereabouts

State / Province
BC
City / Town
Bamfield
Country
Canada

Web Links

Web Site
www.bms.bc.ca
kjurkic
kjurkic
  • Karma
  • Member since
  • Saturday, 13 November 2004 10:35
  • Last online
  • 4 days ago
  • Profile views
  • 409 views
1 week ago
kjurkic replied to the topic Re: version 5.1 email problem in the forums.
Hi Again

FWIW, I did have to restart SMTP afterward. Did you attempt a stop/start?

That other post was after encountering the same problem as you - no email being sent. After clearing some space, I forced an immediate logrotate to see if the huge maillog file was part of the problem.

regards
Ken
May 09
kjurkic replied to the topic Re: egroupware install issue in the forums.
Hi Alex

I have an EGW system hosted on Clear5.2

Could you keep us posted on how your install is progressing? I would like to migrate to Clear6.x soon.

Regards
Ken
May 09
kjurkic created a new topic Alternate Email Archiving Solution in the forums.
Hi All

As a solution to the issues that some have experienced with the email archiving module in ClearOS, I would like to offer my kludge using the email alias feature.

I will note here that this will not likely work well if your userbase is 100's or 1000's of accounts!

First off, you will need to determine your archiving requirements.

In my case, I have three classes - department heads (ie president@ourcompany.com) where communications will need to be kept for years, general contact accounts (info@ourcompany.com, webmaster@ourcompany.com, etc), and lastly, regular accounts (username@ourcompany.com) which will only need about 60 days retention to recover from deletes.

Instead of CLI wizardry, being a script savant, and/or general Postfix/Cyrus guru-ship, all that is needed can be accomplished via the ClearOS Webadmin console.

First go to Directory>Accounts>Users
Create as many archive accounts as you figure you will need. In my case its archive01, archive02, archive03

Next go to Server>Mail>Aliases
Use the Add control panel to create the alias (Must match the valid user account you wish to archive)
For Users - and this is important - select both the username AND the archive name you wish to use. <CTRL><Left-Mouse-Click> to select.
Click the Add button at bottom, and Voila, you are now archiving.

The archives can be accessed using any regular email client, or the Horde webmail interface. You just give the account/password info to whoever will be monitoring the archive and they can run with it from there. They can even reset the password from the normal user login console in ClearOS.

HTH
Ken
May 09
kjurkic replied to the topic Re:Mail Archive in the forums.
Hi Ben

I don't know if this is helpful, but I have been seeing errors in my maillog file in regard to the email.archive user

examples:
IOERROR: appending cache for user.email-archive: File too large

and

IOERROR: mapping cache file for user.email-archive: Cannot allocate memory

Should I be worried about these messages?

FWIW I have come up with an archiving system that can be easily implemented and allows more than one non-overlapping archive (ie Senior Management archive/ regular user archive).

So far its working good, and management of the archive(s) can be delegated to anyone who is an email power-user.

There is a lot of manual setup up-front, and I wouldn't use for more than several hundred users.

regards
Ken
May 09
kjurkic replied to the topic Re:Huge maillog file in the forums.
NEVERMIND

/usr/sbin/logrotate -f /etc/logrotate.conf

to solve
May 09
kjurkic created a new topic Huge maillog file in the forums.
Hi all

I am not sure where to start with investigating this one; the maillog on my server has grown to over 2.2GB. I at 100% use on that volume, and had to purge a few *.4 & *.3 logs.

I don't know where to check to see if logrotate can be reset. Is there a webadmin console for this, or a CLI command?

thanks
Ken
May 09
kjurkic replied to the topic Re:Now on verge of nervous breakdown in the forums.
Hi All

Not quite out of the woods yet, SMTP server quit for some reason, along with maillog no longer accessible from webadmin.

Will start new thread in appropriate category

regards
Ken
May 09
kjurkic replied to the topic Re:Now on verge of nervous breakdown in the forums.
Hi Tim

Tried to post reply earlier, but it got lost with our flaky internet connection

I stopped all tinkering in order to avoid bricking the box. I have been working for the last couple of hours with Clear's support team to try and diagnose the problem.

regards
Ken
PS I have been working with spanning volumes and raid arrays since the mid 90's starting with Netware.
In my own experience, never once has recovering and restoring been an easy task, whereas with h/w raid and partitions limited to single spindles, I have never been down for more than a few hours.
May 08
2 weeks ago
kjurkic replied to the topic Re:Now on verge of nervous breakdown in the forums.
While googling for similar problems, found that others with CentOS and fedora have seen issues of mis-match between grub setting and what fdisk sees, with the added spice of mdadm settings just to add confusion.

My /etc/sysconfig/grub

boot=/dev/md1
forcelba=0

but fdisk reports

"Disk /dev/md126 doesn't contain a valid partition table"
^^^^^^
This is interesting, as /etc/mdadm.conf says the drives should be labelled /dev/md1, /dev/md2, etc

I am too scared to try and edit settings, since if I brick this system, I have no easy way to access the partitions holding data

software RAID really sucks....
May 07
kjurkic created a new topic Now on verge of nervous breakdown in the forums.
I was trying to grab a snapshot of my server, using clonezilla.

SYSTEM: Clearbox 300 with 5.2

After grabbing sdb, I went for a restart, and was slapped in the face with this:

"kernel panic - syncing: Attempted to kill init"

Any advise on how to salvage this situation? What boot disk should I use to try and access & restore? CentOS? ClearOS?

Ken
May 07
kjurkic replied to the topic Re: WebAdmin console reports "degraded" drives in the forums.
Hi Tim

I really do appreciate your assistance; This email server is just one of dozens of servers & workstations I have to support (I have to work in the no-mans-land btw hard-core Windows users and Mac fanbois & grrls who all insist that theirs is the best way)

I had never even looked at the RAID console before today - the email service has been trucking along just fine for the past year, and I have been keeping daily/weekly backups. Only been restarted once in the last year.

I have never been a fan of LVM; always had bad experience with disaster recovery - I prefer old-school where volumes never exceeded a single spindle, along with hardware RAID.

I can see there has been a lot of reconstruction going on.

Code:

[root@mail2 ~]# dmesg | grep md
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
md: raid1 personality registered for level 1
ata1: SATA max UDMA/133 cmd 0x8800 ctl 0x8480 bmdma 0x8000 irq 193
ata2: SATA max UDMA/133 cmd 0x8400 ctl 0x8080 bmdma 0x8008 irq 193
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sda3 ...
md:  adding sda3 ...
md: sda2 has different UUID to sda3
md: sda1 has different UUID to sda3
md: created md3
md: bind<sda3>
md: running: <sda3>
raid1: raid set md3 active with 1 out of 2 mirrors
md: considering sda2 ...
md:  adding sda2 ...
md: sda1 has different UUID to sda2
md: created md2
md: bind<sda2>
md: running: <sda2>
raid1: raid set md2 active with 1 out of 2 mirrors
md: considering sda1 ...
md:  adding sda1 ...
md: created md1
md: bind<sda1>
md: running: <sda1>
raid1: raid set md1 active with 1 out of 2 mirrors
md: ... autorun DONE.
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
EXT3 FS on md1, internal journal
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 120384 blocks.
md: md1: sync done.
md: syncing RAID array md3
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 1927791872 blocks.
md: md3: sync done.

May 06
kjurkic replied to the topic Re:Mail Archive in the forums.
Hi

Have you found the solution to this?

The email-archive in 5.2 appears to be very bug-ridden. I enabled it, but the included webadmin console would not access the archives. I have basically ignored it, then just today found that it had in fact been collecting email messages, just that the included utility was a P.O.S.

Like you, I would like to release & purge these messages.

regards
Ken
May 06

Wall

No wall post to show

My Forum Updates

Groups

Here is a short listing of the groups that the user has registered in.