unRAID Server Release 5.0-rc10 Available

[dgaschk]

In rc.S:

# tmm - here's a hack: loop until /dev/disk/by-label/UNRAID is present
# this serves to synchronize this script with USB subsystem
while [ ! -e /dev/disk/by-label/UNRAID ]; do
  echo "waiting for USB subsystem"
  sleep 1
done

 

Do you really need to do that?  What, wait here forever?

 

You could wait a bit -- if you absolutely must -- but then let the machine finish booting up.

 

If shit has happened we need access to the conssole to see/fix what's wrong.

 

(In have a good idea what could be wrong in this particular scenario, but that's beside the point)

 

You don't like my hack? 

 

I guess I was thinking, if the flash doesn't mount there's nothing much to do and if someone actually sees this I would get an email and could investigate what was going on.

 

It's a mean thing to do.  Seriously.

 

Maybe do something like this:

for i in {1..10} ;do
  if [ -e /dev/disk/by-label/UNRAID ] ;then break ;fi
  echo "waiting for USB subsystem..."
  sleep 1
done

.

Please.

 

Ok I can do that, but did you actually see that message repeating on the console, or are you just poking around in the startup files and saw it?  Like I said, it was put in there so that someone would be sure to let me know if it was happening.

 

I've seen it.

[pras1011]

For future RC program inprovments, I would like an improvement made to the syslog. An issues in the system should be made known to user by putting this info at the end of the boot up syslog etc.

[PleaseWork]

I just upgraded from 5.0-rc5 to 5.0-rc10, and I am now getting "Transport endpoint" errors when attempting to use my samba share.  Post with attached syslog has been made http://lime-technology.com/forum/index.php?topic=25463.msg221528#msg221528:

[RobJ]

For future RC program inprovments, I would like an improvement made to the syslog. An issues in the system should be made known to user by putting this info at the end of the boot up syslog etc.

 

On the surface, that sounds good, bit I don't know what is actually possible.  Can you be more specific about what you would like to see, or provide examples of messages you would like to see?

[pras1011]

Just problems that have been detected by the unraid. In a easy readable format.

[dave_m]

Upgraded to RC10 from beta12a without any problems.  RTL8168D/8111D (8111DL) NIC seems to be working OK and no write speed issues using 8GB of memory, although I wasn't expecting them on an ECS A885GM-A2 AMD motherboard.  An older Rosewill / Realtek PCI NIC worked on my test system as well.

[technojunkie]

Looks like the download link is broken again... When I click the link in the OP or try the download link from the main page, I get a 404 error.

[limetech]

Looks like the download link is broken again... When I click the link in the OP or try the download link from the main page, I get a 404 error.

Site got  "hacked" again.  Here's what's happening.  The hacker is somehow gaining access to the "public_html" directory and they do this:

- replace .htaccess with zero-length .htaccess

- upload an image called 'sejeal.jpg'.  You can google it to see what it looks like.

- upload a file called 'php.class.php' to public_html/tmp.  This file has some binary info at the beginning followed by some php which looks like it implements a file uploader of some kind.

I think once these files are in place the hacker can access /tmp/php.class.php and use that to upload stuff.

 

When this first happened last week I immediate changed all the passwords (amazing how many there are).  But I guess there must be a vulnerability somewhere.     

[MyKroFt]

Are you really running v1.5 of joomla?  Perhaps its time up update to 2.5...

 

Myk

 

[technojunkie]

Thanks for the quick fix

[ratmice]

Looks like the download link is broken again... When I click the link in the OP or try the download link from the main page, I get a 404 error.

Site got  "hacked" again.  Here's what's happening.  The hacker is somehow gaining access to the "public_html" directory and they do this:

- replace .htaccess with zero-length .htaccess

- upload an image called 'sejeal.jpg'.  You can google it to see what it looks like.

- upload a file called 'php.class.php' to public_html/tmp.  This file has some binary info at the beginning followed by some php which looks like it implements a file uploader of some kind.

I think once these files are in place the hacker can access /tmp/php.class.php and use that to upload stuff.

 

When this first happened last week I immediate changed all the passwords (amazing how many there are).  But I guess there must be a vulnerability somewhere.     

 

Here's a tiny bit of info http://www.cyberwarnews.info/tag/sejeal/

 

Same guy did it again today.

[crazytony]

Site got  "hacked" again.  Here's what's happening.  The hacker is somehow gaining access to the "public_html" directory and they do this:

- replace .htaccess with zero-length .htaccess

- upload an image called 'sejeal.jpg'.  You can google it to see what it looks like.

- upload a file called 'php.class.php' to public_html/tmp.  This file has some binary info at the beginning followed by some php which looks like it implements a file uploader of some kind.

I think once these files are in place the hacker can access /tmp/php.class.php and use that to upload stuff.

 

When this first happened last week I immediate changed all the passwords (amazing how many there are).  But I guess there must be a vulnerability somewhere.     

 

Check the access logs for sejeal.jpg,  .htaccess and php.class.php.  I've found that in most cases it points me right to the offending page (url params)

[Tony_YYZ]

Is there an ETA on when the site will be back up and fully running again? I need to purchase two license keys but that portion of the site seems to be down as well as the downloads.

 

Thanks.

[WeeboTech]

Looks like the download link is broken again... When I click the link in the OP or try the download link from the main page, I get a 404 error.

Site got  "hacked" again.  Here's what's happening.  The hacker is somehow gaining access to the "public_html" directory and they do this:

- replace .htaccess with zero-length .htaccess

- upload an image called 'sejeal.jpg'.  You can google it to see what it looks like.

- upload a file called 'php.class.php' to public_html/tmp.  This file has some binary info at the beginning followed by some php which looks like it implements a file uploader of some kind.

I think once these files are in place the hacker can access /tmp/php.class.php and use that to upload stuff.

 

When this first happened last week I immediate changed all the passwords (amazing how many there are).  But I guess there must be a vulnerability somewhere. 

 

Does public_html need to be writable for the site to work? Perhaps remove all write permissions?

does public_html/tmp need to be writable?

Perhaps make the directory owned by root with no permissions?

Do any of these uploaded files exist as part of the current site? if not set some cron job to test and remove them or make then exist with no permission and owned by root.

 

perhaps make all .htaccess files owned by root, with no write permissions and read permissions shared by the web server.

 

You could also create a cron job that rsyncs a list of files every so often.

This way if anything changes, what you want is immediately put back in place.

[NAS]

Its a shared host. Chances are some other domain is letting him in and he is escalating.

 

 

[olympia]

I upgraded from 4.7 to 5.0 rc8a and then quick upgraded to rc10.

 

I just noticed an issue with spin down on rc10 (don't know if it was there or not on rc8a).

It appears that spindown of disks are not always (kind of hit and miss) happening even though I see the spin down command executed in the log file.

 

1682: Jan 24 16:55:03 Tower kernel: mdcmd (84): spindown 10
1681: Jan 24 16:55:02 Tower kernel: mdcmd (83): spindown 7
1680: Jan 24 16:55:02 Tower kernel: mdcmd (82): spindown 6
1679: Jan 24 16:55:01 Tower kernel: mdcmd (81): spindown 5
1678: Jan 24 16:55:01 Tower kernel: mdcmd (80): spindown 4
1677: Jan 24 16:55:00 Tower kernel: mdcmd (79): spindown 3
1676: Jan 24 16:55:00 Tower kernel: mdcmd (78): spindown 2
1675: Jan 24 16:55:00 Tower kernel: mdcmd (77): spindown 1

 

After the above all disks are spinning down, but one, in this case disk 10 which keeps spinning.

In another case, another disk is affected.

 

Does anyone has an idea what can casue this? I saw this reported earlier in this thread by somehow whose unraid box didn't go to sleep due to the same issue.

 

Following that, because unraid think the disk has spun down, it never tries to spun it down again.

 

In case I use the command '/root/mdcmd spindown 10' it spins down immediately and keeps spun down.

 

Is this a potential bug or there is something I can look at on my side?

[joyless]

would anyone be kind enough to upload rc10 somewhere? just bzimage and bzroot would be fine, thanks

[limetech]

would anyone be kind enough to upload rc10 somewhere? just bzimage and bzroot would be fine, thanks

Site is back up.

[limetech]

 

It appears that spindown of disks are not always (kind of hit and miss) happening even though I see the spin down command executed in the log file.

After the above all disks are spinning down, but one, in this case disk 10 which keeps spinning.

In another case, another disk is affected.

 

Following that, because unraid think the disk has spun down, it never tries to spun it down again.

 

In case I use the command '/root/mdcmd spindown 10' it spins down immediately and keeps spun down.

 

Is this a potential bug or there is something I can look at on my side?

Are the colored status balls in the webGui consistent with the disk spinning state?  Also, I'd like to see the full system log.

[olympia]

 

It appears that spindown of disks are not always (kind of hit and miss) happening even though I see the spin down command executed in the log file.

After the above all disks are spinning down, but one, in this case disk 10 which keeps spinning.

In another case, another disk is affected.

 

Following that, because unraid think the disk has spun down, it never tries to spun it down again.

 

In case I use the command '/root/mdcmd spindown 10' it spins down immediately and keeps spun down.

 

Is this a potential bug or there is something I can look at on my side?

Are the colored status balls in the webGui consistent with the disk spinning state?  Also, I'd like to see the full system log.

 

Hi Tom,

 

Yes, the colored status ball reflect correctly to the spinning state. However if I look at unmenu, interestingly it shows the disk as spun down (but unmenu is wrong - probably due to different spinning state checking).

 

I am now removing SimpleFeatures (I already planned for a long time). Will come back with the full system log if the issue persists.

[peter_sm]

I see same thing now , unfortunately I can't get a syslog at the moment

 

In unmeny all disk is spunn down, and in main I see my parity is spinning.

 

Before I have also seen 1 of my data disk is spinning, and rest was spunn down, and all my data disk is on same Spinup group

 

Might be a issue in SF, need do dig in more after my preeclearing is done.....

 

//Peter

 

 

[olympia]

 

It appears that spindown of disks are not always (kind of hit and miss) happening even though I see the spin down command executed in the log file.

After the above all disks are spinning down, but one, in this case disk 10 which keeps spinning.

In another case, another disk is affected.

 

Following that, because unraid think the disk has spun down, it never tries to spun it down again.

 

In case I use the command '/root/mdcmd spindown 10' it spins down immediately and keeps spun down.

 

Is this a potential bug or there is something I can look at on my side?

Are the colored status balls in the webGui consistent with the disk spinning state?  Also, I'd like to see the full system log.

 

Hi Tom,

 

Yes, the colored status ball reflect correctly to the spinning state. However if I look at unmenu, interestingly it shows the disk as spun down (but unmenu is wrong - probably due to different spinning state checking).

 

I am now removing SimpleFeatures (I already planned for a long time). Will come back with the full system log if the issue persists.

 

Hi Tom,

 

OK, I removed SF yesterday evening, but some customization is still running (VBox, CrashPlan and TVHeadend).

Please see the system log attached. FYI at 22:28:17 I was the one who manually spin up all the drives.

 

Today morning I see all the drives, but the cache drive spinning.

 

Let me know if you want me to test with full Vanilla unRAID (by removing every customization), but those apps never caused any issue like that before.

systemlog.txt

[joyless]

r10 won't boot for me. I can't telnet into unRAID, webGUI won't come up either. I'm using Intel NIC. Unfortunately I don't have external monitor right now so I can't diagnose the issue. Unplugged the flash drive, copied back rc9a and it boots fine again.

[nars]

r10 won't boot for me. I can't telnet into unRAID, webGUI won't come up either. I'm using Intel NIC. Unfortunately I don't have external monitor right now so I can't diagnose the issue. Unplugged the flash drive, copied back rc9a and it boots fine again.

 

Note that you may need to re-run the .bat to reinstall syslinux.

[joyless]

r10 won't boot for me. I can't telnet into unRAID, webGUI won't come up either. I'm using Intel NIC. Unfortunately I don't have external monitor right now so I can't diagnose the issue. Unplugged the flash drive, copied back rc9a and it boots fine again.

 

Note that you may need to re-run the .bat to reinstall syslinux.

Thanks, somehow I missed it.

I'm using Mac, so I guess finding Windows machine to run .bat is just too much hassle, I'll wait for the 5.0 final