Symptoms

• running drush @sites pm-update results in normal execution up to after answering ‘y[es]‘; then drush seems to hang indefinitely (haven’t waited beyond about 10 minutes, maybe it does produce an error after a long while);
• running the same command with --debug shows that drush hangs when trying to untar the downloaded module.tar.gz archive; there are no errors/warnings, it just hangs with no CPU usage;
• trying to untar any of the modules downloaded from drupal.org manually is also unsuccessful: tar -xzvf module.tar.gz seems to do nothing, it also hangs with zero CPU usage/time and no warnings/errors;
• interestingly, if I create some test.tar.gz locally, tar does happily extract that;
• finally, running strace tar -xzvf module.tar.gz shows a number of unexpected lines, such as references to NSS and libnss files (I am only showing some of the lines of strace output, including the last line):
  

  open(“/etc/nsswitch.conf”, O_RDONLY) = 4
  read(4, “# /etc/nsswitch.conf\n#\n# Example”…, 4096) = 683
  open(“/lib/x86_64-linux-gnu/libnss_nis.so.2″, O_RDONLY) = 4
  open(“/lib/x86_64-linux-gnu/libnss_files.so.2″, O_RDONLY) = 4
  open(“/etc/passwd”, O_RDONLY|O_CLOEXEC) = 4
  open(“/usr/lib/x86_64-linux-gnu/libnss_mysql.so.2″, O_RDONLY) = 4
  open(“/etc/group”, O_RDONLY|O_CLOEXEC) = 4
  open(“/etc/libnss-mysql.cfg”, O_RDONLY) = -1 EACCES (Permission denied)
  open(“/etc/libnss-mysql-root.cfg”, O_RDONLY) = -1 EACCES (Permission denied)
  futex(0x7fd0816e8c48, FUTEX_WAIT_PRIVATE, 2, NULL

Analysis
strace output provided enough information to understand the issue and generate a workaround. Briefly, we see tar querying users and groups information. On the system where this problem was identified, MySQL is used as a name-service back-end. This is why we see references to mysql libraries in the trace. Apparently, tar is trying to resolve some user/groups information, but for some reason does not get what it is asking in a timely manner, or possibly never gets it and will only fail/proceed when the request times out.

Workaround
Not a solution, but works: tar -xzv --numeric-owner -f module.tar.gz. The --numeric-owner switch asks tar to use numeric file/directory owner information as-is, without trying to resolve the name of the owner. This works. I have not checked strace for the workaround, but I expect to see no MySQL/NSS references in it with the switch.

To actually be able to use drush with this workaround, I had to edit drush.inc somewhere under /usr/share/drush/; look for ‘tar ‘ string, and add --numeric-owner where necessary. Do not forget that -f has to be just in front of the archive filename, otherwise your edits will not work.

I found the reason at debianhelp.org forums. Basically, it’s the PC speaker module (pcspr) not functioning correctly. I suspect this problem manifests itself only on some types of laptops. The solution is either to somehow reconfigure the pcspkr module, or just disable it. More on how to disable the module below.

First of all, boot into console-only mode or even single-user mode. On my install GRUB loader, configured by the Debian Installer, had an option in the boot menu to boot into single-user mode.

Remember, that any sound emission attempt will freeze your computer in this scenario. So avoid any actions, which might generate a system beep. These actions include (but are in no way limited to): using TAB filename/command autocompletion, using up/down arrows in command line when there is nothing in the history above or below the current command, etc.

After successfully booting, remove the pcspkr module: modprobe -r pcspkr (if that doesn’t work, try rmmod pcspkr). Note, that this command only removes pcspkr module for the current session, and the module will be loaded again on next boot.

To permanently disable the pcspkr module, you can blacklist it. To do so, add the line blacklist pcspkr to the /etc/modprobe.d/blacklist.local file. If this file does not exist, you can create it.

On my system I already had /etc/modprobe.d/blacklist file, so I also added blacklist pcspkr line to that file. I did not check which one actually worked for me, but on the next boot pcspkr didn’t load.

I also did one more thing – configured console not to beep. This is done in /etc/inputrc file by uncommenting the following line: set bell-style visible (or you can uncomment set bell-style none to have absolutely no bell notifications).

There’s also a method to disable IPv6 module, which can be adopted for the pcspkr module. However, I didn’t use it – methods listed above helped me.

References other than already cited: how to disable PC speaker, how to disable PC speaker in Etch.

Primary source of information was this post, but I recommend that you follow instructions here.

To add AdSense to your Gallery2 sidebar (when using the Matrix theme as a sample):

1. copy themes/matrix/templates/sidebar.tpl to theme/matrix/templates/local/sidebar.tpl on your server. This is needed to preserve your modifications when the Matrix theme will be upgraded.
2. any further modifications should be done in your newly copied local/sidebar.tpl file.
3. create the file which will contain all your AdSense code – e.g., let it be adsense_160x600.tpl for the Wide Scyscraper format. Put all your AdSense code into that file, and upload the file to your theme/matrix/templates/local/ folder on the server.
4. now edit the sidebar.tpl file. My original file looked like this:[smarty]
   {* Show the sidebar blocks chosen for this theme *}
   {foreach from=$theme.params.sidebarBlocks item=block}
   {g->block type=$block.0 params=$block.1 class=”gbBlock”}
   {/foreach}
   {g->block type=”core.NavigationLinks” class=”gbBlock”}

   [/smarty] I added [smarty]{if $user.isGuest == 1}
   {* adsense code *}
   {g->theme include=”adsense_160x600.tpl” class=”gbBlock”}
   {/if}[/smarty] and final file looked like this:[smarty]{*
   * $Revision: 1.2 $
   * If you want to customize this file, do not edit it directly since future upgrades
   * may overwrite it. Instead, copy it into a new directory called “local” and edit that
   * version. Gallery will look for that file first and use it if it exists.
   *}

   {* Show the sidebar blocks chosen for this theme *}
   {foreach from=$theme.params.sidebarBlocks item=block}
   {g->block type=$block.0 params=$block.1 class=”gbBlock”}
   {/foreach}
   {g->block type=”core.NavigationLinks” class=”gbBlock”}
   {if $user.isGuest == 1}
   {* adsense code *}
   {g->theme include=”adsense_160x600.tpl” class=”gbBlock”}
   {/if}

   [/smarty]

5. well, basically you are done. If you need/want to, you can wrap the inserted code into some styled container, to define the look of the block, like:[smarty]
   {if $user.isGuest == 1}
   {* adsense code *}
   {g->theme include=”adsense_160x600.tpl” class=”gbBlock”}
   {/if}

   [/smarty]

6. you can use any AdSense format you like, but you must mind the width of the sidebar in your theme – so that site layout is not broken by too wide AdSense units.

Finally, some more hints and explanations.

The smarty variables for users in Gallery2 are:

• $user.isGuest
• $user.isRegisteredUser
• $user.isAdmin

As you might have noticed, in the code above AdSense unit is shown ONLY IF the page visitor is a Guest. Thus ads will not be shown to Registered Users and Admin. I did not manage to find this condition in Google’s AdSense Policy, but the source post author states that showing Google Ads in password-protected areas is a violation of Google’s Terms Of Service (TOS). Again – I did not find that, but in good faith I provide the code which limits ads to guest-only users. If you want to show ads to any user class – just remove the first {if} and last {/if} lines from the code. Any knowledgeable comments on this (preferrably with URLs) are very welcome, as personally I see nothing bad in putting AdSense onto password-protected pages in the case of the Gallery, where photos are the main type of content.

To add multiple ad units – create a single file for each distinct ad format/type you want to use, and include it using the code shown above. Just keep in mind limitations imposed by Google on the number of ad units of different types on a single page.

Hope this helps, and good luck to you.

Now there is a Drupal 6.x module available. It is in no way related to the migrate script(s) below.

The newest script version migrates from PHP-Nuke 6.5 to Drupal 5.x.
Download the latest version of the migration script.

In 2002 I set up a PHPNuke-6.0 – based portal. Eventually it died due to the lack of time investments and support from collaborators. Now, when time came to revive the project, I made a search and decided to use Drupal as a base CMS for the portal.
In order to migrate userbase from an old portal to the new Drupal-powered one, and following the topic at drupal.org, I found a script and its modification.
I used it to migrate only users, and made some cosmetic changes:

• added options for custom phpnuke table prefixes
• default user name is now = uname (login), not ‘temp_name’, as before
• I replaced hard-coded links to ‘migrate.php’ with links to $_SERVER['PHP_SELF'], so that if you rename the script you don’t have any problems with that
• now forum topics should not be promoted to the main page (changed 1 to 0 as hinted by Alexis)

Finally, I would like to thank both Karthik Kumar for the original script and Alexis Bellido for the 6.0_to_4.7 modification.

Update: Waldo updated the migration script.
Here are the changes:

• imports from (a security-patched) Nuke 6.5 -> Drupal 5.1
• imports story categories into Drupal taxonomy
• incorporates phpnuke “Contributor writes…” into story
• incorporates phpnuke admin story “note”
• imports polls (does not import record of who already voted. You can easily “close” old phpnuke polls via Admin page. I left them open.)
• imports poll comments
• imports *anonymous* comments for stories, fora, & polls
• imports anonymous forum posts
• filters BBCode to make semi-compatible with Drupal BBCode module
• uses Drupal 5.0 API, and must be run from drupal root directory (/drupal-5/, for example)

Thanks to Waldo for his work!

Latest update: Waldo sent the newest, improved version of the PHP-Nuke-2-Drupal conversion script. Here is Waldo’s description:

New Fixes:

• retain original user registration date & last visit 4/22/07
• fixed user migration bug which could result in screwed max_uid in session table 4/22/07
• store anonymous forum posts names in the log for future compatibility w/Drupal 6 7/16/07
• uses the “tidy” extension (if installed) in php 5.x to clean up the HTML of postings & stories 7/30/07
• bug fixes (possibly) related to drupal 5.2 where the fora had the wrong “changed” date resulting in misordered node lists. 7/30/07
• polls properly remember date of last comment 7/30/07

If you have the “tidy” PHP extension, it should close all open HTML tags and stuff in stories.

update: I added to the script some more debug messages in case something goes wrong (as recommended by me) – that pushed the version up to 0.03.

Also, now MySQL connection collation is set to utf8 before doing anything – this should fix the problems with non-English characters in the imported texts (especially accented/umlauted/etc characters). Thus I upped the version to 0.04. For reference and in case 0.04 doesn’t work for you, I keep the older versions as well.

Download the latest phpnuke2drupal-5.x-0.04-W.zip or the latest tar-gzipped version of the phpnuke2drupal migration script.

update: to import Reviews and WebLinks from PHPNuke to Drupal, have a look at this and this comments; you will need CCK, and might need CCK Link Field to import reviews/weblinks.

Previous (older) versions:
phpnuke2drupal-5.x-0.03-W.zip
phpnuke2drupal-5.x-0.03-W.tar.gz
phpnuke2drupal-5.x-0.02-w.zip
phpnuke2drupal-5.x-0.02-w.tar.gz
phpnuke2drupal-5.x-0.01 (VValdo’s huge improvements first appear here)
first version with my minor modifications

IMPORTANT: for migration to work you will need MySQL version to be >= 4.1.1. Earlier versions do not support the STR_TO_DATE() function, used in the migration script.

IMPORTANT: if you want to migrate forum entries from PHPNuke to Drupal, be sure to setup forum in your Drupal installation first – otherwise migration of forum entries will fail. See comments 13-17 below for user experiences.

If you do not get any help here, there is also a drupal.org migration thread. I will keep this page updated for as long as I get new information about the migration script.

If you encounter any problems during migration – just search/scan the comments, your problem might have been already solved by someone else.