SchoolBusDriver

Members
  • Posts

    204
  • Joined

  • Last visited

Posts posted by SchoolBusDriver

  1. HTPC Manager unRAID Plugin

     

    The old HTPC Manager Project died but Styxit and others have picked it back. They have made 770 commits already and are still working on it daily.

     

    New HTPC Manager Website

     

    Main Screen from one of my unRAID Boxes

     

    zHixQav.png

     

    CouchPotato

     

    xExTOHP.png

     

    SABnzdb

     

    SykQe3s.png

     

    sabNZDB

     

    bTQrosc.png

     

    Stats

     

    UXLQGt4.png

     

    NOTES:

     

    If you want to make HTPC Manager (or Maraschino) your default program when going to your unRAID server address.

     

    Edit the go file on the unRAID USB Stick

     

    nano /boot/config/go

     

    Change the unRAID emhttp line from this...

     

    /usr/local/sbin/emhttp &

     

    To this (-p defines what port emhttp will listen too)

     

    /usr/local/sbin/emhttp -p 5000 &

     

    Restart unRAID for it to take effect.

     

    After you restart and access unRAID with the new HTTP port

     

    Go to the Settings Tab and change either HTPC Manager or Maraschino to port 80.

     

    You MUST run them as user root or else it will not work. Make your life easy and add unRAID to the Applications Module in either HTPC Manager or Maraschino.

     

    Missing Package for Stats to work (PhAzE will eventually add it to his GitHub or elsewhere)

     

    I had to compile a missing package for the stats page to work. I do not have a place to store it where the plugin will automatically download it during install. HTPC Manager will work fine without it but the stats tab will not. Until PhAzE has a chance to convert this plugin, if you want to use the stats page:

     

    Download Link ---> psutil-2.1.1-i486-1.tgz to /boot/packages on your unRAID USB Flash Drive and install it.

     

    installpkg /boot/packages/psutil-2.1.1-i486-1.tgz

     

    You will need to stop / restart the HTPC Manager after you install the package. Once PhAzE adds it to his Github and updates the plugin, everything will be automated.

     

    Stats Configuration Page

     

    Ignore the directions on the HTPC Manager Configuration Page and do not put a comma between different entries (filesystems, mount points, etc).

     

    My Ignore Mountpoint (notice I put spaces and not commas like it tells you too

     

    /mnt/disk1 /mnt/disk2 /mnt/disk3 /mnt/user /var/log /proc/fs/nfs

     

    HTPC Manager Plugin

     

    htpcmanager.plg <---- Download link

  2. HTPC Manager unRAID Plugin

     

    The old HTPC Manager Project died but Styxit and others have picked it back. They have made 770 commits already and are still working on it daily.

     

    New HTPC Manager Website

     

    Main Screen from one of my unRAID Boxes

     

    zHixQav.png

     

    CouchPotato

     

    xExTOHP.png

     

    SABnzdb

     

    SykQe3s.png

     

    sabNZDB

     

    bTQrosc.png

     

    Stats

     

    UXLQGt4.png

     

    NOTES:

     

    If you want to make HTPC Manager (or Maraschino) your default program when going to your unRAID server address.

     

    Edit the go file on the unRAID USB Stick

     

    nano /boot/config/go

     

    Change the unRAID emhttp line from this...

     

    /usr/local/sbin/emhttp &

     

    To this (-p defines what port emhttp will listen too)

     

    /usr/local/sbin/emhttp -p 5000 &

     

    Restart unRAID for it to take effect.

     

    After you restart and access unRAID with the new HTTP port

     

    Go to the Settings Tab and change either HTPC Manager or Maraschino to port 80.

     

    You MUST run them as user root or else it will not work. Make your life easy and add unRAID to the Applications Module in either HTPC Manager or Maraschino.

     

    Missing Package for Stats to work (PhAzE will eventually add it to his GitHub or elsewhere)

     

    I had to compile a missing package for the stats page to work. I do not have a place to store it where the plugin will automatically download it during install. HTPC Manager will work fine without it but the stats tab will not. Until PhAzE has a chance to convert this plugin, if you want to use the stats page:

     

    Download Link ---> psutil-2.1.1-i486-1.tgz to /boot/packages on your unRAID USB Flash Drive and install it.

     

    installpkg /boot/packages/psutil-2.1.1-i486-1.tgz

     

    You will need to stop / restart the HTPC Manager after you install the package. Once PhAzE adds it to his Github and updates the plugin, everything will be automated.

     

    Stats Configuration Page

     

    Ignore the directions on the HTPC Manager Configuration Page and do not put a comma between different entries (filesystems, mount points, etc).

     

    My Ignore Mountpoint (notice I put spaces and not commas like it tells you too

     

    /mnt/disk1 /mnt/disk2 /mnt/disk3 /mnt/user /var/log /proc/fs/nfs

     

    HTPC Manager Plugin

     

    htpcmanager.plg <---- Download link

  3. Unless the RC wiki is wrong I think Ironic is dead on. See here last updated today. http://wiki.xen.org/wiki/Xen_4.4_RC4_test_instructions. Looks like they have a little way to go to fix the bugs.

     

    burt

     

    My bad... The Release will be out by the end of the month but still working through some issues and the latest Release Candidates is version 4.

     

    Tom has to wait for someone to create a build package for it or figure it out himself (no easy task!).

  4. I'm confused as to why "as a plugin" is an option? Nano a native package. Anyone can install it and place it in /boot/extra.

     

    I agree.

     

    Nano as a plugin is crazy considering the size of it, what it is and pretty much any documentation / blogs / guides a Linux noob will see on the Web will use nano over VIM.

     

    Personally... I am not writing a guide or posting a VM Appliance until the next beta (which will have nano in it). Like it or not, for users to do a lot of the Xen / VM Appliance stuff it requires editing some cfg files.

     

    If that isn't isn't hard enough... Imagine writing a guide and having to explain to a novice how to use VIM on top of that...

     

    Hit "a", then add what you want, hit "esc" and move there to delete, hit "d", then "del" until it's gone, then hit "esc", then ":", then "w" and then "q", etc.

     

    Screw that noise!

     

    The dorks that get off on VIM can continue to use it and impress their dork friends on how "cool" they are. The rest of us will use nano.

     

    Bigger picture: I'd much rather see a progression towards modularity than an appeal to have packages added to the core.

     

    What were you thinking? Any ideas / suggestions on how to do this?

  5. so do you have file: twice?

     

    Yes

     

    name = "debcloud"

    memory = 512

    vcpus = '2'

    disk = [

    'file:/net/unraid/mnt/user/Media/Software/ISOs/debian7.4.iso,xvdd:cdrom,r',

    'file:/mnt/ownCloud/debian.img,xvda,w'

    ]

    vif = [ 'mac=00:16:3e:a1:bc:a4,bridge=br0' ]

    bootloader = "pygrub"

    bootloader_args = "--kernel=/install.amd/xen/vmlinuz --ramdisk=/install.amd/xen/initrd.gz"

  6. From what I am seeing in various forums is many people jumping ship from tvheadend to VDR.

     

    I haven't used either in a long time but you might want to checkout VDR and see where it is compared to tvheadend.

     

    As far as tvheadend working well on unRAID without a VM... True.

     

    However...

     

    1. You have to hope other plugins don't crash it or your unRAID WebGUI.

    2. You are totally dependent on one person to update tvheadend plugin whereas in a VM you simple run one command to update it.

    3. You cannot use all the functions like transcoding because they cause issues with Plex, serviio, etc.

    4. Still no 64-Bit version.

    5. You would have to compile a custom kernel in the 64-Bit version to add your TV Card possibly.

    6. 64-Bit doesn't solve the problem with number 3 above.

  7. If you want to do your own install here's the config file I used.

     

    name = "debcloud"
    memory = 512
    vcpus = '2'
    disk = [ 
    'file:/net/unraid/mnt/user/Media/Software/ISOs/debian7.4.iso,xvdd:cdrom,r', 
            'phy:/mnt/ownCloud/debian.img,xvda,w'
    ]
    vif = [ 'mac=00:16:3e:a1:bc:a4,bridge=br0' ]
    bootloader = "pygrub"
    bootloader_args = "--kernel=/install.amd/xen/vmlinuz --ramdisk=/install.amd/xen/initrd.gz"
    
    

     

    Ironic... It works, but you probably want to change the way you do cfg files and update your image / documentation.

     

    You use...

     

    phy:/mnt/ownCloud/debian.img,xvda,w

     

    That is for lvm, disks, etc.

     

    Instead of...

     

    file:/mnt/ownCloud/debian.img,xvda,w

     

    Which is for img, ISOs, VHDs, cow, cow2, etc. files.

     

    If the users continue to use this, later versions of Xen (or if we goto libvirt and import them) it could break it. Plus when looking at documentation / guides online they will not see "phy" unless the documentation is using disks, volumes, etc. in their examples.

     

  8. @SchoolBusDriver

    is this necessary to add to syslinux.cfg as well ?

     

    iommu=1
    

     

    That isn't my call to make.

     

    I am making suggestions to Tom from his point of view with everyone in mind.

     

    I haven't tried running Xen with iommu=1 on a motherboard / bios that doesn't support / do IOMMU to see what happens (good, bad, nothing).

     

    If I was Tom, I would leave it out. When someone wants to do PCI Passthrough they will follow a guide and have to add the PCI Device IDs to syslinux.cfg anyway. Adding iommu=1 at the same time shouldn't be an issue. Plus, I suspect that the people who do need / use PCI Passthrough will be small compared to those who do not.

  9. It might be helpful if when people post about issues with 6.0-beta, they also include the details of their syslinux.cfg file (whether it is stock with the 2GB mem limit, no CPU limit) or their custom changes.

     

    I noticed issues right away when I first started using 6.0-beta with the 2GB limit, and started installing 64-bit versions of the plugins I was using with unRaid 5.0.  I removed the memory limit, and have had no issues since.  Once I begin to migrate my plugins to VMs, I will then re-evaluate the memory and CPU resources I assign to Dom0 unRaid.

     

    I suggested the following and Tom has said they are going into the next release:

     

    1. Do not assign a set amount of memory to Dom0 and make syslinux.cfg look like this:

     

    label Xen 4.3.1 / unRAID OS
      kernel /syslinux/mboot.c32
      append /xen dom0_max_vcpus=1 dom0_vcpus_pin --- /bzimage --- /bzroot
    label Xen 4.3.1 / unRAID OS Safe Mode (no plugins)
      kernel /syslinux/mboot.c32
      append /xen  --- /bzimage --- /bzroot unraidsafemode
    

     

    Since a lot of people use a Cache Directories (a memory hog), let Dom0 get assigned all the memory. That way if memory runs low, the VM has the issues / crash (as a previous user a few posts up experienced) and not unRAID.

     

    Even with all the memory assigned to Dom0 (unRAID), the VMs can still use / grab it but unRAID has the priority and will take back what it needs.

     

    Note - By default, this how most Linux Distros handle it.

     

    2. You will probably want to dedicate at least one CPU to Dom0 by default.

     

    label Xen 4.3.1 / unRAID OS
      kernel /syslinux/mboot.c32
      append /xen dom0_max_vcpus=1 dom0_vcpus_pin --- /bzimage --- /bzroot
    label Xen 4.3.1 / unRAID OS Safe Mode (no plugins)
      kernel /syslinux/mboot.c32
      append /xen --- /bzimage --- /bzroot unraidsafemode
    

     

      a) Dedicating a CPU core only for dom0 makes sure dom0 always has free CPU time to process the IO requests for the domUs.

     

      b) When dom0 has a dedicated core there are less CPU context switches to do, giving better performance.

     

      c) Assigning more than one isn't going to make Dom0, write files faster to unRAID or make the VMs run any faster.

     

  10. Does any one have any benchmarks to back up the claim of Plex performance bare metal vs VM?

     

    We aren't reinventing the wheel or blazing new trails in Virtualization.

     

    Businesses / Enterprises have been virtualizing MILLIONs of Servers which run very complex multi-million apps like ERP, Video Conferencing, etc. for over a decade.

     

    There are PLENTY of users here in the unRAID forum who use Plexx in a VM in either XenServer or ESXi. Not to mention the MILLIONS of home users who run ESXi / XenServer with Plex in a VM (who don't use unRAID and posts in other forums).

     

    Simply put... You won't notice any difference with your Plex App running in a VM with Paravirtualized Drivers compared to bare metal.

  11. Thanks for that, but that's exactly what I'm attempting to do as USB controller passthrough is proving unreliable.

     

    However, without 'lsusb', I cannot enumerate my usb devices, unless there's another way?

     

    Here you go...

     

    wget http://ftp.lip6.fr/pub/linux/distributions/slackware/slackware64-14.1/slackware64/a/usbutils-007-x86_64-1.txz
    
    installpkg usbutils-007-x86_64-1.txz

  12. Was there a guide posted on how to expand ironics arch.img or has there been another arch.img posted somewhere?

     

    You have 4 options...

     

    Option A

     

    Shrink / Expand Ironics image.

     

    Issues:

     

    1. You can't do it in unRAID. You have to do it in a regular Linux Distro.

     

    2. It's very COMPLICATED and not noob friendly.

     

    Option B

     

    1. Create a 25GB, 50GB, 100GB, etc. whatever image file ("data drive").

     

    cd /mnt/cache/VMs/ArchVM/ # <--- Location of where you VM Appliance is stored

    truncate -s 100G data.img # <--- Enter the size of the of your "data drive" for your VM Appliance

     

    2. Format your "data drive" with ext4.

     

    mkfs.ext4 /mnt/cache/VMs/ArchVM/data.img

     

    3. Add this "data drive" to your VM Appliance cfg file.

     

    Example:

    name = "archVM"

    bootloader = "pygrub"

    memory = 1024

    vcpus = 1

    bootloader = "pygrub"

     

    disk = [

    'file:/mnt/cache/VMs/ArchVM/arch.img,xvda,w',

    # 'file:/mnt/cache/VMs/ArchVM/data.img,xvdb,w' # <--- Uncomment this if adding a "Data Drive"

    ]

    vif = [ 'mac=00:16:3e:xx:xx:xx,bridge=br0' ] # <--- Replace xx with random lower case letters and numbers so your MAC Address is unique.

     

    4. Start your VM Appliance and login as root.

     

    5. Create a data folder in the root.

     

    mkdir /data

     

    6. Change ownership and permissions

     

    chown -R nobody:users /data

    chmod - R 777 /data

     

    7. Edit fstab and mount the "data drive" to /data

     

    nano /etc/fstab

     

    Example of what to add:

     

    /dev/xvdb              /data        ext4      defaults,noatime      0      2

     

    8. Users will configure Plex, sabnzbd, Sickbeard, Transmission, etc. to use /data in the VM for where they store Plex stuff. Plus where they download, unrar, etc. stuff before it's moved to unRAID.

     

    Option C

     

    Ironic post several images of various sizes (5GB,10GB, 50GB, 100GB, etc.) for his All In One VM Appliance. (or add this to page one on how to create a "data drive" in a VM)

     

    Option D

     

    Ironic has a Plex, XBMC, Usenet Indexer, Owncloud, etc. VM Appliance of various sizes (5GB, 10GB, 50GB, 100GB, etc.) or use Option B above. (or add this to page one on how to create a "data drive" in a VM)

     

    Issues:

     

    I mentioned separating things like Plex and creating a Plex VM Appliance (like you would an XBMC one) but Ironic doesn't want to create / support more than one VM Appliance and he did not think it was a good idea for running several VM Appliances either. He prefers an All In One approach.

     

    Typically XenServer and ESXi people have Usenet Indexers, MakeMKV (converting, ripping, etc. Blurays / DVDs / Video Files), Plex, XBMC, etc. running in their own VM Appliance. Why do we do that?

     

    1. Some Applications are more memory, CPU, network, database, etc. intensive than others. It's best you separate those if you can and have more "control" over the VM and the resources you assign to them.

     

    2. With Plex, Usenet Indexers, MakeMKV, XBMC, sabnzb, sickbeard all running at once along with copying / moving files to unRAID via Samba / NFS, etc... EVERYTHING is going through ONE NIC and you have no option to split that traffic between multiple NICs. (See: Networking inside Xen)

     

    3. Usenet Indexers, XBMC, Plex, owncloud, etc. can / do have their own database that you run in Mysql (Mariadb) and many of us do not want every app all in one Mysql instance but prefer separate ones. Usenet Indexer would be a great example of this. The data is HUGE and where everything is stored. It also makes backing up your MySQL database easier too.

     

    4. When you update / upgrade the underlying Linux Distro or complex programs like Usenet Indexers, XBMC, Plex, etc. you could break one App, several or all of them. What is the point of being able to run multiple VMs and keep your unRAID "clean" but duplicate the orginal problem and put all your eggs (all your apps) into one VM Appliance. If it breaks, has issues, etc... You lose one, several or all the Apps that you run in an All In One.

     

    Hopefully others will post VM Appliances in the near future... Some we could use are:

     

    pfSense

    XBMC

    Usenet Indexer

    Owncloud

    unTangled

    Tvheadend

    VDR

    A Hardened / Secured VM Appliance where users can have it sit outside their Firewall and add Apps they want to have access from the Web. 

    Etc.

  13. I didn't post anything about licensing, but the code has neither an open source license nor any copyrighted note in it. The problem involved co-ordination as much as the use of the code. The code was forked and still calling the same name with only a rev bump. That screwed the original author over since his same named code and revision order was now messed up and he would also be looked to for supporting that forked code since he is the creator and supporter of the code with that name.

     

    Assuming it is open source, there are still good reasons why someone forking a piece of open source software creates a new name and new development location with a new revision code. None of that was done in this preclear case.

     

    Believe it or not, we actually agree on something. Informative and good post.

  14. I'm not sure of the exact service name but have a look in the following directory for your 'custom' services.

     

    /etc/systemd/system/multi-user.target.wants/

     

    Actually when you install apps / services / sockets / targets / slices / tools / libraries / etc all the systemd files are installed in the following directory:

     

    /usr/lib/systemd/system

     

    That is where you will find things like xbmc, nfs, samba, mysql and all kinds of various things linux uses / needs during start up. There will be 175+ (Mine has 230) systemd files in that directory.

     

    When you find what you want simply type

     

    systemctl enable airvideoserver   <--- just an example, your command may need adjusting
    

     

    When you run the above command.. It creates a symbolic link from /usr/lib/systemd/system to /etc/systemd/system and depending on the app / socket / service / slice / target it can either be in system or multiuser. Usually multiuser for 90% of things users will run into.

  15. If unRAID wants to really use VM's to give the average user extra capabilities then there needs to be full VM capabilites with no command line work needed and the capability needs to be created and supported through LimeTech, not as a user plugin.

     

    I agree. Hopefully in time either Tom or a user develops a Plugin or WebGUI that is point and click.

     

    As for the poll itself - I think it's useless...

     

    You are right. Tom has said he adding it in the next release.

     

    And as for posting crap comments about Joe L. - I fully expect him to be around long after anyone posting crap about him dissappears and even if he dissappeared tomorrow it would take many years before anyone else ever provides as much unRAID support as he has during his time here. The made-up stories are rather funny. The issue was that the pre-clear script was modified without asking and instead of asking and going forward working together the GUI project was dropped.

     

    1. Nobody said crap comments about Joe.

     

    2. Joe did get pissed, he demanded the guy remove it from his GUI all of those are true / facts.

     

    3. Neither Speeding Ant or Joe was bad just a difference of opinion.

     

    4. Preclear is open source. If Speeding Ant or I want to take to preclear, use it as in another product, modify it, add it to a GUI for unRAID or FreeNAS...  Anyone can do it and there is NOTHING wrong with it.

  16. I'm working on a way to let you enlarge the .IMG as you see fit. Looks fairly easy but I haven't had chance to test it yet.

     

    1. Why?

     

    2. The users will not be able to do it in unRAID 6.0. The img file has a partition and multipath and various Linux tools you need to mount it are not enabled / installed in unRAID.

     

    3. Assuming multipath was enabled / installed... A user would have to extend the image file, extend the partition and then extend the file system. That isn't easy.

     

    The best option is going to be to start a list of apps and where their configs are, maybe we could collectively write a backup script for the .INI files?

     

    1. Your "job" is to provide VM Appliances that users install and configure / customize to their liking and keep your repo up to date.

     

    2. You need to have a bunch of VM Appliances not a all encompassing ONE. Otherwise you are going to make your life / the users life hell. People who run ESXi and XenServer have SEVERAL VM Appliances not just ONE. Why would you do anything different?

     

    3. Why would a user need to continue to download your image, install it over their old one when Sickbeard has an update?

     

    The user would do the following instead:

     

    pacman -Syyu

     

    The user should only have to install VM Appliances once and keep it updated not continue to install image after image.

     

    Option A

     

    It's easier to have multiple versions of the same VM Appliance but have different sizes of it available for download (if you / they do not like Option B below).

     

    Option B

     

    1. Provide instructions on how to create a 25, 50, 100GB, etc. whatever image file ("data drive") and how to format it with ext4.

     

    2. Provide instructions on how to add this "data drive" to the cfg file.

     

    Example:

    name = "archVM"

    bootloader = "pygrub"

    memory = 1024

    vcpus = 1

    bootloader = "pygrub"

     

    disk = [

    'file:/mnt/cache/VMs/ArchVM/arch.img,xvda,w',

    # 'file:/mnt/cache/VMs/ArchVM/data.img,xvdb,w' # <--- Uncomment this if adding a "Data Drive"

    ]

    vif = [ 'mac=00:16:3e:xx:xx:xx,bridge=br0' ] # <--- Replace xx with random lower case letters and numbers so your MAC Address is unique.

     

    Within your image, create a data folder in the root. In the /etc/fstab have a commented out mount for it and provide instructions on how to uncomment it out.

     

    Example:

     

    #/dev/xvdb              /data        ext4      defaults,noatime      0      2 # <--- Uncomment this if you have a "Data Drive"

     

    Going forward the users will configure sabnzbd, Sickbeard, Transmission, etc. to use /data in the VM for where they download, unrar, etc. stuff before it's moved to unRAID.

     

    A few other things you need to consider

     

    1. Create several Vanilla Arch VM Appliances (of various sizes or option B above) and provide instructions for installing the apps.

     

    If I install you vanilla image and I only want / use Sabnzbd, Sickbeard, Couchpotato, Headphones... All I have to do is:

     

    pacman -S sabnzbd sickbeard couchpotato headphones

     

    To enable start on boot (or you could edit your packages to do it for them):

    systemctl enable sabnzbd
    systemctl enable sickbeard
    systemctl enable couchpotato
    systemctl enable headphones

     

    2. Create separate dedicated VM Appliances for complex things like Plex, XBMC, Usenet Indexers, etc. This is how everyone does it now if they have a ESXi or XenServer... So you should do it too.

     

    3. All in one solution with all those apps installed running in one VM is a receipt for disaster and you are going to have 945 versions of it and you still want make everyone happy. It sort of defeats the purpose of running VMs in the first place. I would have several different VM Appliances.

     

    For example:

     

    VM Appliance - sabnzbd, sickbeard, couchpotato, headphones, media front end and torrents

     

    VM Appliance - Plex

     

    VM Appliance - XBMC

     

    VM Appliance - Owncloud

     

    This is a VM Appliance / App people will probably want outside their firewall. If so, they are going to want to secure / harden this VM Appliance (might want to consider something other than Arch).

     

    VM Appliance - Vanilla Arch (with instructions on how to install the various apps of their choice)

     

  17. Evidence of previous breaks in the design isnt justification for future ones.

     

    I say again i don't care about nano. I do care about the upswell in assuming people are comfortable using it and our seeming blazaness to alienating a % of the userbase because of it.

     

    We are not going to agree on this.

     

    My preference is the same as yours... WebGUIs / Plugins that work 100% of the time and do not crash the server.

     

    Reality... Neither exist today and there isn't anyone interested or volunteering to write / develop the WebGUIs and Plugins we will need.

     

    I'm willing to chip in some money to see if we can get this done. Are you? If so, how much are willing to donate?

  18. Never crash before x64. Therefore i do not believe its hardware related.  But i really love the Xen tools and do not want to go back to the 32 bit system =(

     

    We are in Beta... Bugs / Issues are going to pop up that need to be addressed and fixed. Hence, the discount for a second unRAID License Key for those of us who have more than one server.

     

    If this is a production machine, wait till the next release to see if some / all of the bugs you are experiencing are worked out.