The MetaArray is a group of multicore, multiraid, high performance nodes which provide computational and data storage/hosting services for MetaARPA members. The current disk quota for each user is 800 GB and will likely increase with time.

Users of the MetaArray must agree to abide by the MetaArray Acceptable Use Policy

To enable your access to ma.sdf.org, run 'metaarray' at the shell. This will first generate a random login password followed by a random database password sent via local e-mail if you have a DBA membership. To connect, use 'ssh ma.sdf.org' (port 22 or 8080). Once you are connected, you can change your password with the 'passwd' command. If you ever forget your password, just run 'metaarray' again from any of the regular nodes of the SDF cluster.

The MetaArray Logical Volume spans multiple Volume Groups across multiple Physical Volumes which are organized as multiple disk drives organized in multiple hardware RAID level 5 groups. To the user, this all appears to be under one contiguous file system: /meta

The user directory structure is as follows:

Packages on the MetaArray are managed with pkgsrc and yum. Nearly any program or package can be installed by making a request on the regular nodes of the SDF cluster via the 'bboard' REQUESTS.

The package directory structure is as follows:

The MetaArray includes all features of the MetaARPA membership. However, some SDF specific utilities may not be available on the MetaArray because it is designed to be isolated from the SDF cluster. Some MetaArray specific services must be manually configured by the user.

To host your personal website on the MetaArray, please do the following:

• run 'mkhomepg' on the MetaArray. This creates the $HOME/html symlink and sets initial permissions.
• upload your site to $HOME/html on the MetaArray.
• run 'mkhomepg' again on the MetaArray. This sets proper permissions on your content.
• run 'mkhomepg -t' on the SDF cluster to toggle your site to the MetaArray

It may take up to 10 minutes for DNS to update locally; however your ISP DNS server may cache this data for up to 12 hours so you won't see the change immediately. Use the “host” command on the cluster to see if DNS has changed, and “lynx” on the cluster to verify that the site loads: then be patient as DNS changes propagate.

* The DOCROOT for your directory defaults to no-read access, so you must have an index.html. Directory listings will work on subdirs within the DOCROOT. You can defeat this by running 'chmod g+r $HOME/html'

* https through a self signed certificate is only available to personal URLs under *.sdf.org

SDF makes available a Nextcloud ¹⁾ instance at https://ma.sdf.org/nc/.

To initialize your login, go to https://ma.sdf.org/nc/, click “Forgot password?”, and enter your SDF username.

In order to connect to your instance from a client, the “server” should be set to “https://ma.sdf.org/nc/”. (The client might complain about the *.sdf.org SSL certificate, but that's fine)

If you'd like to use SDF's Nextcloud as a destination for ShareX then follow the steps below: note: This tutorial was written for 10.1

• Configure ShareX Destination for SDF Nextcloud
• Open the ShareX application window
• Click on Destinations
• Click on Destination Settings
• Select on the left pane, Nextcloud (under File uploaders)
• Enter:
  • Host: https://ma.sdf.org/nc
  • Username: your sdf_nc login
  • Password: your sdf_nc password
  • Path: /foo
• Place a check next to:
  • Create shareable URL (Optional)
  • Ignore invalid SSL certificate (Required)
• Close the settings window
• Select from the menu: Image Uploader - File Uploader - Nextcloud

$Id: metaarray.html,v 1.38 2018/08/15 02:09:33 echosa Exp $ The MetaArray - traditional link (using RCS)