hurikhan77's questions

We deployed a new Server 2012 Essentials and joined a client computer to the domain using CCW. This PC initially showed up in the Essentials Dashboard.

Later we joined a few more PCs to the domain and now found that these do not show up in the dashboard. Even the PC that was initially listed does no longer show up there. So something must have gone wrong during the process of configuring the server.

We found no way to get the PCs listed. They are listed in ActiveDirectory, however. A common suggestion we found using Google is to disconnect the computers and rejoin them using CCW. But I'm not happy with that solution so we did not try that. I don't like disconnecting the PCs from the domain because that will probably loose configuration and data already associated in the dashboard. And I'm not sure it will work because there's still the question: Why does the PC initially listed in dashboard no longer show up?

The main problem with this is that computers are no longer available through the RWW website and our customer wants to use this feature for remotely working on the office PCs.

We are running courier currently which enables us to set different SQL userdb queries for IMAP and POP3. We need this because we do not want to give all users IMAP access, a boolean column in the userdb allows IMAP access if set.

For performance and stability reasons we are currently migrating to dovecot. I found no way yet to either set different SQL queries based on POP3 or IMAP access - or to pass the access method as variable to the SQL query. Both ways would work.

Here's the relevant mysql config from courier:

MYSQL_SELECT_CLAUSE SELECT \
  username,password_enc,password,uid,gid,homedir,maildir,'',CONCAT(\
    IF(isimap=1 OR '$(service)'='webmail','disableimap=0,','disableimap=1,'),\
    'disablepop3=0,disablewebmail=0'\
  )\
  FROM mail_users WHERE username = '$(local_part)@$(domain)'

The service variable comes from the daemon config file. Is there something similar in dovecot?

Since upgrading a Gentoo box from postfix 2.5.5 to 2.6.6, local mail delivery does no longer work. Virtual mailboxes still work.

Here's the log:

Jul 14 13:07:05 weser postfix/master[15825]: warning: process /usr/lib/postfix/local pid 20065 killed by signal 11
Jul 14 13:07:05 weser postfix/master[15825]: warning: /usr/lib/postfix/local: bad command startup -- throttling
Jul 14 13:07:05 weser postfix/qmgr[15829]: warning: private/local socket: malformed response
Jul 14 13:07:05 weser postfix/qmgr[15829]: warning: transport local failure -- see a previous warning/fatal/panic logfile record for the problem description
Jul 14 13:07:05 weser postfix/error[20067]: 5D2A3466D56C: to=<[email protected]>, orig_to=<[email protected]>, relay=none, delay=6.9, delays=6.7/0.05/0/0.08, dsn=4.3.0, status=deferred (unknown mail transport error)

Where weser.XXX.YY is the local machine. I tried the -v switch on local and qmgr but it didn't help me very much.

I'm pretty clueless how to debug any further. Trying to trace the processes with debugger_command didn't generate any expected output files.

Questions:

1. How do I debug that any further?
2. Are there any caveats I should've known of before upgrading from 2.5 to 2.6?

Update: I managed to get a strace log, and it looks like the segfault immediatly occurs after reading the spool file from the active queue.

Update 2: I managed to get a coredump and created a backtrace:

#0  0x138f9469 in vstring_strcpy (vp=0x13929630, src=0x0) at vstring.c:409
#1  0x138e66d9 in dict_db_lookup (dict=0x139295b0, name=0x0) at dict_db.c:200
#2  0x138bd83e in deliver_alias (state=
      {level = 1, msg_attr = {level = 0, fp = 0x1392f630, queue_name = 0x1392f520 "active", queue_id = 0x1392f248 "0658546584CA", offset = 218, encoding = 0x1390b018 "", sender = 0x1390b018 "", dsn_envid = 0x1390b018 "", dsn_ret = 0, rcpt = {offset = 191, dsn_orcpt = 0x1390b018 "", dsn_notify = 0, orig_addr = 0x1392f5e0 "[email protected]", address = 0x1392f608 "[email protected]", u = {status = 0, queue = 0x0, addr_type = 0x0}}, domain = 0x0, local = 0x0, user = 0x0, extension = 0x0, unmatched = 0x0, owner = 0x0, delivered = 0x0, relay = 0x5d8f4a53 "local", msg_stats = {incoming_arrival = {tv_sec = 1279051621, tv_usec = 25651}, active_arrival = {tv_sec = 1279121939, tv_usec = 42594}, agent_handoff = {tv_sec = 1279121939, tv_usec = 124639}, conn_setup_done = {tv_sec = 0, tv_usec = 0}, deliver_done = {tv_sec = 0, tv_usec = 0}, reuse_count = 0}, exp_type = 0, exp_from = 0x0, request = 0x1392eb88, why = 0x1392f700}, dup_filter = 0x13931360, loop_info = 0x1392fa18, request = 0x1392eb88}, usr_attr={uid = 0, gid = 0, home = 0x0, logname = 0x0, shell = 0x0}, name=0x0, statusp=0x5d8f3d58)
    at alias.c:199
#3  0x138c3df9 in deliver_switch (state=
      {level = 1, msg_attr = {level = 0, fp = 0x1392f630, queue_name = 0x1392f520 "active", queue_id = 0x1392f248 "0658546584CA", offset = 218, encoding = 0x1390b018 "", sender = 0x1390b018 "", dsn_envid = 0x1390b018 "", dsn_ret = 0, rcpt = {offset = 191, dsn_orcpt = 0x1390b018 "", dsn_notify = 0, orig_addr = 0x1392f5e0 "[email protected]", address = 0x1392f608 "[email protected]", u = {status = 0, queue = 0x0, addr_type = 0x0}}, domain = 0x0, local = 0x0, user = 0x0, extension = 0x0, unmatched = 0x0, owner = 0x0, delivered = 0x0, relay = 0x5d8f4a53 "local", msg_stats = {incoming_arrival = {tv_sec = 1279051621, tv_usec = 25651}, active_arrival = {tv_sec = 1279121939, tv_usec = 42594}, agent_handoff = {tv_sec = 1279121939, tv_usec = 124639}, conn_setup_done = {tv_sec = 0, tv_usec = 0}, deliver_done = {tv_sec = 0, tv_usec = 0}, reuse_count = 0}, exp_type = 0, exp_from = 0x0, request = 0x1392eb88, why = 0x1392f700}, dup_filter = 0x13931360, loop_info = 0x1392fa18, request = 0x1392eb88}, usr_attr={uid = 0, gid = 0, home = 0x0, logname = 0x0, shell = 0x0}) at recipient.c:135
#4  0x138c4af8 in deliver_recipient (state=
      {level = 1, msg_attr = {level = 0, fp = 0x1392f630, queue_name = 0x1392f520 "active", queue_id = 0x1392f248 "0658546584CA", offset = 218, encoding = 0x1390b018 "", sender = 0x1390b018 "", dsn_envid = 0x1390b018 "", dsn_ret = 0, rcpt = {offset = 191, dsn_orcpt = 0x1390b018 "", dsn_notify = 0, orig_addr = 0x1392f5e0 "[email protected]", address = 0x1392f608 "[email protected]", u = {status = 0, queue = 0x0, addr_type = 0x0}}, domain = 0x1393145d "weser.XXX.YY", local = 0x13931458 "root", user = 0x13931480 "root", extension = 0x0, unmatched = 0x0, owner = 0x0, delivered = 0x1392f608 "[email protected]", relay = 0x5d8f4a53 "local", msg_stats = {incoming_arrival = {tv_sec = 1279051621, tv_usec = 25651}, active_arrival = {tv_sec = 1279121939, tv_usec = 42594}, agent_handoff = {tv_sec = 1279121939, tv_usec = 124639}, conn_setup_done = {tv_sec = 0, tv_usec = 0}, deliver_done = {tv_sec = 0, tv_usec = 0}, reuse_count = 0}, exp_type = 0, exp_from = 0x0, request = 0x1392eb88, why = 0x1392f700}, dup_filter = 0x13931360, loop_info = 0x1392fa18, request = 0x1392eb88}, usr_attr=
      {uid = 0, gid = 0, home = 0x0, logname = 0x0, shell = 0x0}) at recipient.c:319
#5  0x138c2246 in local_deliver (rqst=0x1392eb88, service=0x5d8f4a53 "local") at local.c:718
#6  0x138c23c5 in local_service (stream=0x1392daa8, service=0x5d8f4a53 "local", argv=0x5d8f4990) at local.c:756
#7  0x138c7c53 in single_server_wakeup (fd=14) at single_server.c:262
#8  0x138c7e1d in single_server_accept_local (unused_event=1, context=0x6 <Address 0x6 out of bounds>) at single_server.c:304
#9  0x138ed896 in event_loop (delay=-1) at events.c:1086
#10 0x138c8bd6 in single_server_main (argc=3, argv=0x5d8f4984, service=0x138c2351 <local_service>) at single_server.c:732
#11 0x138c2892 in main (argc=3, argv=0x5d8f4984) at local.c:917

Environment:

We are running multiple web, database, and application servers which usually share a pretty common installation (gentoo linux) and similar configuration in VMware ESXi 4. The differences are usually only some installed features or differing component versions. To create a new server, I usually choose the most similar (by features) running server, rsync a copy of it into freshly mounted filesystems, run grub, reconfigure and reboot.

Problem:

Over time this duplicates many on-disk data blocks which probably sums up to several 10's of gigabytes. I suppose if I could use a base system as template with the actual machines based on top of that, only writing changed blocks to some sort of "diff image", performance should improve (increased cache hit rate) and storage efficiency should increase (deduplicated storage space). This would be similar to what ESXi already supports for RAM deduplication (page sharing).

Question:

Is there any way to easily do this on ESXi 4? I already share the portage tree via NFS but this would not work for the rootfs.

We just installed an option card (PERC 6/i) into a brand-new Dell PowerEdge R410 and now the system does no unattended startup but instead asks me to press F1 to continue or F2 to enter system setup after printing the following message on the console:

Fan 4 speed may change depending on system configuration and option card install.

How do I make the system ignore this "problem" or whatever that is? This system is going to be installed at a remote data center and needs to be able to restart unattended. I do not want to ignore errors completely to not get endless restart loops in case of errors.

One of our older legacy servers which gets no further updates or reconfigurations suddenly stopped resolving hostnames to IPs when PHP is executed within Apache. However, it still works fine when executed from the CLI.

From the RSS caches last modification time, I deduce that it stopped working on around Mar, 28th.

To reproduce the problem, I created a script using fsockopen() and it said "connection failed (errno 2)". I further reduced the problem to being related with a failed name resolution:

<?php $addr = gethostbyname("twitter.com"); echo "ADDR($addr)"; ?>

When I run this through Apache, the output is ADDR(twitter.com), which is wrong.

When I run this from the CLI, the output is ADDR(aaa.bbb.ccc.ddd) with varying IP addresses, as expected.

Nothing on the server setup has changed. CLI and Apache module share the same php.ini. PHP is version v4.4.9 with Zend Optimizer v2.5.10. Apache is v1.3.31.

I know the versions are old. But since nothing has been changed, a solution like "try to upgrade versions first" is no solution as the server's feature set/versioning is frozen and will be replaced soon. Still we need a solution.

If I run dig through the script, it works in both environments (mod_php and CLI) but this is more than an ugly hack as it would involve many edits and testing throughout the whole script base which is also undesired as the PHP application on the server is frozen, too, and only receives security updates. It will be replaced by a complete rewrite (on the new server).

But as the rewrite will take some time and successive replace parts of the legacy application, we need a fix for the resolver problem. I already googled a bit and while the problem is known, many did not find a fix. The fix to raise memory limits did not work. Restarts did not work. The resolver in mod_php just did stop working for no apparent reason. :-(

Update: I solved it meanwhile by fully stopping apache, waiting for a moment, then starting it again. But that doesn't explain the root cause for this behaviour (and thus there's no satisfying solution). So I leave this open.

On one linux server (Gentoo hardened), we are experiencing bursts of the following messages in dmesg from time to time:

TCP: Treason uncloaked! Peer xx.xx.xxx.xxx:65039/80 shrinks window 4094157295:4094160199. Repaired.

Is there anything we should take care of or is this normal?

Update: Maybe related, we are using net.ipv4.tcp_congestion_control = cubic. Kernel version is 2.6.28 with Gentoo hardening patches.

Update: This could probably really be related to hardware/driver issues, as we are seeing a "hickup" on the switches sometimes: The port goes down and comes up again. Only lately we discovered the following dmesg output related to these port hickups:

[5781269.910133] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[5781269.910136]   Tx Queue             <0>
[5781269.910137]   TDH                  <e0>
[5781269.910139]   TDT                  <76>
[5781269.910140]   next_to_use          <76>
[5781269.910141]   next_to_clean        <da>
[5781269.910143] buffer_info[next_to_clean]
[5781269.910144]   time_stamp           <22750e54>
[5781269.910146]   next_to_watch        <e2>
[5781269.910147]   jiffies              <22750f5f>
[5781269.910148]   next_to_watch.status <0>

Usually after these logged lines there also follow some "Treason uncloaked" lines (but not vice versa, means these are not always logged before "Treason uncloaked").

As an example given the django-9999 ebuild, to match a developer's environment I need to checkout R12120 from trunk. Installing Django manually is not an option due to package management reasons. But there is also no ebuild in portage for 1.2 beta versions.

So I did the following:

ESVN_OPTIONS="-r12120" emerge -1a django

Which installed the required revision from svn. But this is cumbersome in a way. Is there some way to define this statically per ebuild, eg something like:

DJANGO_SVN_REV="12120"

in make.conf. This would be much cleaner in my eyes.

Because next time I need to rebuild django for whatever reason, I need to remember: "Oh I wanted this to stick to a specific revision" and next question will be "err, f&!#$?%, what was it again?"

What's the best way to go here?

Keep in mind:

• Manually installing packages without package manager knowledge is no option
• Working around with manual emerge variable prefixing is no option
• Setting up a /etc/portage/package.env would be a way to go (as described here) but that seems pretty unsupported and kludgy to me and thus unpreferable
• Modifying make.conf would be a way to go
• Keeping the ebuild in an overlay would be an option

Many people recommend block-level cloning over file-level cloning - besides various reasons - mainly because of its superior speed advantage. And true: Data transfer rates are about 50-75% percent faster using block-level cloning from my observations. But after some testing I figured out that it is still slow as hell because there is one big fat difference that heavily falls into account: The amount of data copied...

While file-level cloning only copies the occupied space (which is usually a fraction of the complete disk in our setups), block-level cloning copies every and each sector - may it be empty or not. This also defeats the purpose of thin disk provisioning as the resulting disk image does not seem to be sparse but instead eagerly filled with zeros where the original disk image had empty space.

So my questions are: How do you skip empty space during block-level cloning? And how do you make the converter not write empty space into the thin provisioned disk?

The cloning operation was P2V, with the source being Windows Server 2003 Web Edition and the destination being ESXi 4.

PS: The question is not about why the performance drawbacks are (this is a question of metadata vs payload, eg cloning many small files should usually still benefit from block-level cloning).

The backup performance of a BackupExec installation suddenly dropped by 50-70% for no apparent reason. The was no user intervention, no reconfiguration, nor updates, and all tapes were affected at once. The system is deployed on a Windows 2003 SBS 32-Bit system, no remote agents involved (except the local one, means: no networking involved).

I do not find any clues about the cause of the failure. The result is that the backup is automatically cancelled after 6 hours where it took 4 hours before and it only walked about 50% of the files and 20% of the data volume opposed to a usual complete backup run. The capacity of the tape is also not used (90% before, now only a fraction of it).

I tried to turn of the single instance backups and also tried turning of using snapshot providers to no avail.

There is no error message as the backup job times out before it can finish (so in fact the error is "backup job did not complete within time" or similar).

Update: The problem persists with or without AOFO. We also ran the cleaning tape. 4 tapes are in use since about 2 years, one tape is pretty fresh. Both generations of tapes show the same issues so it seems not related to the tape. However we are going to try again with a brand-new one.

Any ideas how to debug this?

We had once a working setup per .htaccess to redirect a visitor to a canonical URL (for SEO reasons, reduce double content) if she or he visited our rails app:

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*) http://www.example.com/$1 [L,R=301]

This should essentially mean: If the browser points at something else than example.com, redirect it to www.example.com by 301. This setup used to work before but is now failing. There are no errors, it just does not work if accessing non-existing content or if accessing URIs provided by the rails application. If I put a static file or php file in RAILS_ROOT/public and access that however the redirect is working.

Our rails application is deployed using passenger. The .htaccess file is placed in RAILS_ROOT/public. It seems to have stopped working since updating one of the components but we cannot exactly tell when that was. The passenger module hasn't been updated since a while so I almast would like to exclude that from the list of causes.

Any clue how to work around this or restore the functionality by going another way?

Using: Gentoo Linux, Apache 2.2.11, Passenger 2.0.6

A passenger upgrade is currently not really an option due to its modified symlink resolution behaviour.