Related
I want update project settings for existing Rundeck Project. For example : add resources / nodes to the Rundeck project using CLI. How do I do that?
Solution:
Below is the command using Rundeck CLI to add a resource file in .xml format to an existing Rundeck project
$ rd projects configure set -p MG-Test-CLI --
--resources.source.1.config.file="/home/rundeck/iidas/resources.xml" \ --resources.source.1.config.generateFileAutomatically=true
--resources.source.1.config.includeServerNode=true
--resources.source.1.type=file
Here more useful Rundeck CLI project commands:
# create project
rd projects create -p project1
# get project configuration
rd projects configure get -p project1
# Configure nodes from remote URL (GitLab)
rd projects configure update -p project1 -- \
--resources.source.1.type=url \
--resources.source.1.config.url='https://git.i.example.com/api/v4/projects/3/repository/files/project1%2Fdev%2Fnodes.json/raw?ref=master&private_token=1234567890' \
--resources.source.1.config.timeout=10 \
--resources.source.1.config.cache=false
See also Rundeck CLI documentation and project parameter.
I need to transfer db from app_1 to app_2
I created backup on app_1
Then ran:
heroku pg:backups restore HEROKU_POSTGRESQL_COLOR --app app_2 heroku pgbackups:url --app app_1
HEROKU_POSTGRESQL_COLOR = database URL for app_2
Then I get:
! `pg:backups` is not a heroku command.
! Perhaps you meant `pgbackups`.
! See `heroku help` for a list of available commands.
So I ran:
heroku pgbackups:restore HEROKU_POSTGRESQL_COLOR --app app_2 heroku pgbackups:url --app app_1
Then I get the following:
! WARNING: Destructive Action
! This command will affect the app: app_2
! To proceed, type "app_2" or re-run this command with --confirm app_2
So I confirmed with:
> app_2
! Please add the pgbackups addon first via:
! heroku addons:add pgbackups
So then I ran: heroku addons:add pgbackups --app app_2
Adding pgbackups on app_2... failed
! Add-on plan not found.
Is there a way around this issue? any help would be greatly appreciated!
* Solution *
I ended up emailing Heroku, they advised that I need to heroku update; heroku plugins:update but heroku update is only available to heroku toolbelt only and I had the gem installed.
Solution:
Install Heroku toolbelt here
Then uninstall the gem:
gem uninstall heroku --all
run the following to get the version and it should output heroku-toolbelt, instead of the gem, more info here
$ heroku --version
heroku-toolbelt/2.39.0 (x86_64-darwin10.8.0) ruby/1.9.3
To copy the databases over:
heroku pg:backups restore `heroku pgbackups:url --app app_1` HEROKU_POSTGRESQL_COLOR --app app_2
But even better—you can copy directly from one database to another without needing the backup:
Assuming app_2 database url is: HEROKU_POSTGRESQL_GOLD
heroku pg:copy app_1::DATABASE_URL GOLD -a app_2
That will copy the main database from app_1 to the GOLd database on app_2
its only 1 command to copy database from app to app now you don't have to backup:
heroku pg:copy app_name_to_copy_from::database_color_to_copy_from database_color_to_copy_to --app app_name_to_copy_to
check it here
If you look at heroku docs it says
PG Backups as an add-on has been deprecated. The commands exist as part of the Heroku Postgres namespace in the CLI. The new functionality is live and available for use.
So you can use the pgbackups functionality directly without having to add any add-ons
To create a backup you can run
heroku pg:backups capture --app app_name
if you have multiple databases then you can specify database url like this
heroku pg:backups capture HEROKU_POSTGRESQL_PINK
To restore from a backup on another app you can run
heroku pg:backups restore b001 DATABASE_URL --app app_name
You can transfer database by
heroku pg:copy DATABASE_URL HEROKU_POSTGRESQL_PINK_URL --app app_name
You can also upload your database to a public url and then use that url to import database on another app by
heroku pg:backups public-url b001 --app app_name
and then import it by
heroku pg:backups restore 'https://s3.amazonaws.com/me/items/3H0q/mydb.dump' DATABASE -a app_name
If you are moving from one app to another and want to use same database for another app then you can follow these steps:
Login to your heroku account
Select your old app and go to settings tab
Reveal config vars for your old app
Copy DATABASE_URL
Go back and select your new app
Replace new apps DATABASE_URL with the old apps value
I needed something slightly different so sharing it here:
heroku pg:copy name_of_app_being_copied::DATABASE_URL DATABASE_URL --app name_of_app_being_copied_to
Note: Both references to DATABASE_URL do not need to be changed. It may seem odd, but the first instance references the database url for the app being copied and the second one references the database url of the app being copied to.
heroku pg:copy app1_name::HEROKU_POSTGRESQL_ONYX_URL HEROKU_POSTGRESQL_AQUA_URL --app app2_name
Where the second db url is on app2_name
There are simple ways to do this, and there is a fast way to do it
The simple ways generally involve using a backup/restore methodology (including pg:copy, which is a backup that streams the data directly to a pg_restore process), but these are slow in creating the new database because you are restoring a logical definition of tables, loading the data, and creating indexes on the data.
That's a lot of work, and for my 30GB standard-2 databases it can literally take hours.
The fast way to do it is to provision a follower of the database to be copied (e.g. production) on the application you want the data on (e.g. test). On the same 30GB databases that take hours to do a restore, this last took about 15 minutes.
The methodology I use is:
# Get the name of the source database addon (e.g. postgresql-clean-12345)
heroku pg:info -a production-app
# Create a follower on the destination app (choose your own plan)
# You create the follower on the new app because otherwise it is
# perpetually associated with the source as it's "billing app"
heroku addons:create heroku-postgresql:standard-2 --follow postgresql-clean-12345 -a test-app
heroku pg:wait -a test-app
# Quiesce the destination app
heroku scale web=0 worker=0 -a test-app
heroku maintenance:on -a test-app
# Get the colour of the new database (e.g. HEROKU_POSTGRESQL_GRAY_URL)
heroku pg:info -a test-app
# Unfollow the source database.
# If you want to upgrade the database, do that now instead of the
# unfollow.
heroku pg:unfollow HEROKU_POSTGRESQL_GRAY_URL -a test-app
# Promote the new database on the destination app
heroku pg:promote HEROKU_POSTGRESQL_GRAY_URL -a test-app
# Get the colour of the old database, if any(e.g. HEROKU_POSTGRESQL_MAROON_URL)
heroku pg:info -a test-app
# Destroy the old database (if any)
heroku addons:destroy HEROKU_POSTGRESQL_MAROON_URL -a test-app
# Bring the test app back up
heroku scale web=1 worker=1 -a test-app
heroku maintenance:off -a test-app
Why is this faster?
I believe that when creating a follower, Heroku creates the new database by either copying data files or restoring from a physical (file) backup, then replaying the logs to bring it up to date.
I found the simpler solution to reuse/share the same resource (postgres database in this case - or any others that allow sharing/reuse) with more than one app on heroku is doing the following:
Go to the older (source) app dashboard on Heroku
Select the "Resources" tab
Locate the resource (postgres database, in our case here)
Click on the icon next to the plan name at the right most part of the row listing the resource
Select the "Attach to another app" option and select the newer (target) app name from the list that shows up
Sample of the extended menu mentioned # step #4 above!
That's all it takes to share the resource between the apps as it automatically updates all the related configuration settings on the target app. This comes handy since none of the add-on related configuration variables are directly editable, at least from the dashboard (have not checked through the CLI). Hope this helps anyone looking for similar thing.
As per the website the addon is depreciated. So that could be the reason for the failure message.
Backups as an add-on has been deprecated.
Since your aim is to move the db from one app to another, why don't you try the instructions mentioned in the link below.
https://devcenter.heroku.com/articles/heroku-postgres-backups#direct-database-to-database-copies
heroku addons:create heroku-postgresql:standard-0 --fork postgresql-translucent-12345 --app target-app
Where postgresql-translucent-12345 is the addon name of the database you want to fork from. Note that the color url does not work across different apps but the addon name does.
You can also add the "--fast" option:
heroku addons:create heroku-postgresql:standard-0 --fork postgresql-translucent-12345 --fast --app target-app
Which creates a fork of the database that could be up to 30 hours old. Even without the fast option, I copied a 40GB database in 10 minutes-ish.
https://devcenter.heroku.com/articles/heroku-postgres-fork
Then you have to, of course, promote the database. See David Aldridge's answer -and my comments- above for some further details about the process.
I had a related issue. You can save a backup to your local machine, then upload it to some hosting, like amazon s3, and import from given url.
This question and following answer may help you: Can't import to heroku postgres database from dump
You may find useful pgAdmin III (http://pgadmin.org/), a free db management tool specifically designed to do these types of tasks. You can edit/view/import/export from/to your Heroku db directly. Let me know if you need help in setup. (It's like MySQL Workbench, but for PostgreSQL).
Is there an easy way to create a new Wildfly server instance.
In JBoss AS5 all you had to do is create a copy of default or all and start jboss with:
run.sh -c [New instance name]
There is no such option available in standalone.sh
The change which started with the JBoss AS7 and continues in WildFly is, the whole server configuration is hold in a single file. There are prepared some 4 default configurations (or profiles):
default (standalone.xml - used by default - without clustering and messaging)
HA (standalone-ha.xml - supports clustering)
Full (standalone-full.xml - supports messaging)
Full HA (standalone-full-ha.xml - supports both messaging and clustering)
To use the custom profile start the server with using -c switch
./standalone.sh -c standalone-full-ha.xml
If you only need to change the server configuration, you can edit the profile XML files directly, use CLI tool (jboss-cli.sh/bat) or management console.
If you want to do bigger changes (e.g. different applications in standalone/deployments directory), you can copy the whole standalone directory and edit each copy as necessary. I use following way for starting two clustered server:
cd $JBOSS_HOME
cp -r standalone standalone1; cp -r standalone standalone2
# edit the configs here if necessary ...
bin/standalone.sh -c standalone-ha.xml \
-Djboss.server.base.dir=`pwd`/standalone1 \
-Djboss.node.name=host1 &
bin/standalone.sh -c standalone-ha.xml \
-Djboss.server.base.dir=`pwd`/standalone2 \
-Djboss.node.name=host2 \
-Djboss.socket.binding.port-offset=200 &
This example creates 2 copies from a clean standalone configuration and starts a server for each copy. The second server have port offset 200 (e.g. web running on port 8280).
For standalone instances you can use the --server-config or -c option to specify a different configuration.
For example, to put JBoss in "clustered" mode
$JBOSS_HOME/bin/standalone.sh --server-config=standalone-ha.xml
Other alternative is used a domain mode configuration, in this mode you can define different profiles, for an different servers instances.
WildFly - Operating modes
WildFly - Domain Setup
How to deploy a meteor application to my own server?
flavour 1: the development and deployment server are the same;
flavour 2: the development server is one (maybe my localhost) and the deployment server is another (maybe a VPS in the cloud);
flavour 3: I want to make a "meteor hosting" domain, just like "meteor.com". Is it possible? How?
Update:
I'm running Ubuntu and I don't want to "demeteorize" the application. Thank you.
Meteor documentation currently says:
"[...] you need to provide Node.js 0.8 and a MongoDB server. You can
then run the application by invoking node, specifying the HTTP port
for the application to listen on, and the MongoDB endpoint."
So, among the several ways to install Node.js, I got it up and running following the best advice I found, which is basically unpacking the latest version available directly in the official Node.JS website, already compiled for Linux (64 bits, in my case):
# Does NOT need to be root user:
# create directory
mkdir -p ~/.nodes && cd ~/.nodes
# download latest Node.js distribution
curl -O http://nodejs.org/dist/v0.10.13/node-v0.10.13-linux-x64.tar.gz
# unpack it
tar -xzf node-v0.10.13-linux-x64.tar.gz
# discard it
rm node-v0.10.13-linux-x64.tar.gz
# rename unpacked folder
mv node-v0.10.13-linux-x64 0.10.13
# create symlink
ln -s 0.10.13 current
# add path to PATH
export PATH="~/.nodes/current/bin:$PATH"
# check
node --version
npm --version
And to install MongoDB, I simply followed the instructions in the MongoDB manual available in the Documentation section of its official website:
# Needs to be root user (apply "sudo" if not at root shell)
apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10
echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | tee /etc/apt/sources.list.d/10gen.list
apt-get update
apt-get install mongodb-10gen
The server is ready to run Meteor applications! For deployment, the main "issue" is where the "bundle" operation happens. We need to run meteor bundle command from inside the application source files tree. For example:
cd ~/leaderboard
meteor bundle leaderboard.tar.gz
If the deployment will happen in another server (flavour 2), we need to upload the bundle tar.gz file to it, using sftp, ftp, or any other file transfer method. Once the file is there, we follow both Meteor documentation and the README file which is magically included in the root of the bundle tree:
# unpack the bundle
tar -xvzf leaderboard.tar.gz
# discard tar.gz file
rm leaderboard.tar.gz
# rebuild native packages
pushd bundle/programs/server/node_modules
rm -r fibers
npm install fibers#1.0.1
popd
# setup environment variables
export MONGO_URL='mongodb://localhost'
export ROOT_URL='http://example.com'
export PORT=3000
# start the server
node main.js
If the deployment will be in the same server (flavour 1), the bundle tar.gz file is already there, and we don't need to recompile the native packages. (Just jump the corresponding section above.)
Cool! With these steps, I've got the "Leaderboard" example deployed to my custom server, not "meteor.com"... (only to learn and value their services!)
I still have to make it run on port 80 (I plan to use NginX for this), persist environment variables, start Node.JS dettached from terminal, et cetera... I am aware this setup in a "barely naked" one... just the base, the first step, basic foundation stones.
The application has been "manually" deployed, without taking advantage of all meteor deploy command magic features... I've seen people published their "meteor.sh" and "meteoric.sh" and I am following the same path... create a script to emulate the "single command deploy" feature... aware that in the near future all this stuff will be part of the pioneer Meteor explorers only, as it will grow into a whole Galaxy! and most of these issues will be an archaic thing of the past.
Anyway, I am very happy to see how fast the deployed application runs in the cheapest VPS ever, with a surprisingly low latency and almost instant simultaneous updates in several distinct browsers. Fantastic!
Thank you!!!
Try Meteor Up too
With that you can deploy into any Ubuntu server. This uses meteor build command internally. And used by many for deploying production apps.
I created Meteor Up to allow developers to deploy production quality Meteor apps until Galaxy comes.
I would recommend flavor two with a separate deployment server. Separation of concerns leads to a more stable environment for your code and its easier to debug.
To do it, there's the excellent Meteoric bash script that helps you deploy to Amazon's EC2 or your own server.
As for how to roll your own meteor.com, I suggest you break that out into it's own StackOverflow question as it's not related. Plus, I can't answer it :)
I done with it few days ago. I deployed my Meteor application to my own server on the DigitalOcean. I used Meteor Up tool for managing deploys and Nginx on the server to serve the app.
It's very simple to use. You should install meteor up with the command:
npm install -g mup
Then create the folder for deployment configuration and go to the created directory. Then run mup init command. It will created two configuration files. We are have interest for mup.json file. It have configurations for deployment process. It's looks like this:
{
// Server authentication info
"servers": [
{
"host": "hostname",
"username": "root",
"password": "password",
// or pem file (ssh based authentication)
//"pem": "~/.ssh/id_rsa",
// Also, for non-standard ssh port use this
//"sshOptions": { "port" : 49154 },
// server specific environment variables
"env": {}
}
],
// Install MongoDB on the server. Does not destroy the local MongoDB on future setups
"setupMongo": true,
// WARNING: Node.js is required! Only skip if you already have Node.js installed on server.
"setupNode": true,
// WARNING: nodeVersion defaults to 0.10.36 if omitted. Do not use v, just the version number.
"nodeVersion": "0.10.36",
// Install PhantomJS on the server
"setupPhantom": true,
// Show a progress bar during the upload of the bundle to the server.
// Might cause an error in some rare cases if set to true, for instance in Shippable CI
"enableUploadProgressBar": true,
// Application name (no spaces).
"appName": "meteor",
// Location of app (local directory). This can reference '~' as the users home directory.
// i.e., "app": "~/Meteor/my-app",
// This is the same as the line below.
"app": "/Users/arunoda/Meteor/my-app",
// Configure environment
// ROOT_URL must be set to https://YOURDOMAIN.com when using the spiderable package & force SSL
// your NGINX proxy or Cloudflare. When using just Meteor on SSL without spiderable this is not necessary
"env": {
"PORT": 80,
"ROOT_URL": "http://myapp.com",
"MONGO_URL": "mongodb://arunoda:fd8dsjsfh7#hanso.mongohq.com:10023/MyApp",
"MAIL_URL": "smtp://postmaster%40myapp.mailgun.org:adj87sjhd7s#smtp.mailgun.org:587/"
},
// Meteor Up checks if the app comes online just after the deployment.
// Before mup checks that, it will wait for the number of seconds configured below.
"deployCheckWaitTime": 15
}
After you fill all data fields you can start the setup process with command mup setup. It will setup your server.
After sucessfull setup you can deploy your app. Just type mup deploy in the console.
Another alternative is to just develop on your own server to start with.
I just created a Digital Ocean box and then connected my Cloud9 IDE account.
Now, I can develop right on the machine in a Cloud IDE and deployment is easy--just copying files.
I created a tutorial that shows exactly how my set up works.
I had a lot of trouble with meteor up, so I decided writing my own deploy script. I also added additional info how to set up nginx or mongodb. Hope it helps!
See /sh folder in repository
What the script meteor-deploy.sh does:
Select environment (./meteor-deploy.sh for staging, ./meteor-deploy.sh prod for production)
Build and bundle production version of the meteor app
Copy bundle to server
SSH into server
Do a mongodump to backup database
Stop the running app
Unpack bundle
Overwrite app files
Re-install app node package dependencies
Start the app (uses forever)
Tested for the following server configurations:
Ubuntu 14.04.4 LTS
meteor --version 1.3.2.4
node --version v0.10.41
npm --version 3.10.3
Python's http.server (or SimpleHTTPServer for Python 2) is a great way of serve the contents of the current directory from the command line:
python -m http.server
However, as far as web servers go, it's very slooooow...
It behaves as though it's single threaded, and occasionally causes timeout errors when loading JavaScript AMD modules using RequireJS. It can take five to ten seconds to load a simple page with no images.
What's a faster alternative that is just as convenient?
http-server for node.js is very convenient, and is a lot faster than Python's SimpleHTTPServer. This is primarily because it uses asynchronous IO for concurrent handling of requests, instead of serialising requests.
Installation
Install node.js if you haven't already. Then use the node package manager (npm) to install the package, using the -g option to install globally. If you're on Windows you'll need a prompt with administrator permissions, and on Linux/OSX you'll want to sudo the command:
npm install http-server -g
This will download any required dependencies and install http-server.
Use
Now, from any directory, you can type:
http-server [path] [options]
Path is optional, defaulting to ./public if it exists, otherwise ./.
Options are [defaults]:
-p The port number to listen on [8080]
-a The host address to bind to [localhost]
-i Display directory index pages [True]
-s or --silent Silent mode won't log to the console
-h or --help Displays help message and exits
So to serve the current directory on port 8000, type:
http-server -p 8000
I recommend: Twisted (http://twistedmatrix.com)
an event-driven networking engine written in Python and licensed under the open source MIT license.
It's cross-platform and was preinstalled on OS X 10.5 to 10.12. Amongst other things you can start up a simple web server in the current directory with:
twistd -no web --path=.
Details
Explanation of Options (see twistd --help for more):
-n, --nodaemon don't daemonize, don't use default umask of 0077
-o, --no_save do not save state on shutdown
"web" is a Command that runs a simple web server on top of the Twisted async engine. It also accepts command line options (after the "web" command - see twistd web --help for more):
--path= <path> is either a specific file or a directory to be
set as the root of the web server. Use this if you
have a directory full of HTML, cgi, php3, epy, or rpy
files or any other files that you want to be served up
raw.
There are also a bunch of other commands such as:
conch A Conch SSH service.
dns A domain name server.
ftp An FTP server.
inetd An inetd(8) replacement.
mail An email service
... etc
Installation
Ubuntu
sudo apt-get install python-twisted-web (or python-twisted for the full engine)
Mac OS-X (comes preinstalled on 10.5 - 10.12, or is available in MacPorts and through Pip)
sudo port install py-twisted
Windows
installer available for download at http://twistedmatrix.com/
HTTPS
Twisted can also utilise security certificates to encrypt the connection. Use this with your existing --path and --port (for plain HTTP) options.
twistd -no web -c cert.pem -k privkey.pem --https=4433
go 1.0 includes a http server & util for serving files with a few lines of code.
package main
import (
"fmt"; "log"; "net/http"
)
func main() {
fmt.Println("Serving files in the current directory on port 8080")
http.Handle("/", http.FileServer(http.Dir(".")))
err := http.ListenAndServe(":8080", nil)
if err != nil {
log.Fatal("ListenAndServe: ", err)
}
}
Run this source using go run myserver.go or to build an executable go build myserver.go
Try webfs, it's tiny and doesn't depend on having a platform like node.js or python installed.
If you use Mercurial, you can use the built in HTTP server. In the folder you wish to serve up:
hg serve
From the docs:
export the repository via HTTP
Start a local HTTP repository browser and pull server.
By default, the server logs accesses to stdout and errors to
stderr. Use the "-A" and "-E" options to log to files.
options:
-A --accesslog name of access log file to write to
-d --daemon run server in background
--daemon-pipefds used internally by daemon mode
-E --errorlog name of error log file to write to
-p --port port to listen on (default: 8000)
-a --address address to listen on (default: all interfaces)
--prefix prefix path to serve from (default: server root)
-n --name name to show in web pages (default: working dir)
--webdir-conf name of the webdir config file (serve more than one repo)
--pid-file name of file to write process ID to
--stdio for remote clients
-t --templates web templates to use
--style template style to use
-6 --ipv6 use IPv6 in addition to IPv4
--certificate SSL certificate file
use "hg -v help serve" to show global options
Here's another. It's a Chrome Extension
Once installed you can run it by creating a new tab in Chrome and clicking the apps button near the top left
It has a simple gui. Click choose folder, then click the http://127.0.0.1:8887 link
https://www.youtube.com/watch?v=AK6swHiPtew
I found python -m http.server unreliable—some responses would take seconds.
Now I use a server called Ran https://github.com/m3ng9i/ran
Ran: a simple static web server written in Go
Also consider devd a small webserver written in go. Binaries for many platforms are available here.
devd -ol path/to/files/to/serve
It's small, fast, and provides some interesting optional features like live-reloading when your files change.
If you have PHP installed you could use the builtin server.
php -S 0:8080
give polpetta a try ...
npm install -g polpetta
then you can
polpetta ~/folder
and you are ready to go :-)
Using Servez as a server
Download Servez
Install It, Run it
Choose the folder to serve
Pick "Start"
Go to http://localhost:8080 or pick "Launch Browser"
Note: I threw this together because Web Server for Chrome is going away since Chrome is removing support for apps and because I support art students who have zero experience with the command line
Yet another node based simple command line server
https://github.com/greggman/servez-cli
Written partly in response to http-server having issues, particularly on windows.
installation
Install node.js then
npm install -g servez
usage
servez [options] [path]
With no path it serves the current folder.
By default it serves index.html for folder paths if it exists. It serves a directory listing for folders otherwise. It also serves CORS headers. You can optionally turn on basic authentication with --username=somename --password=somepass and you can serve https.
I like live-server. It is fast and has a nice live reload feature, which is very convenient during developpement.
Usage is very simple:
cd ~/Sites/
live-server
By default it creates a server with IP 127.0.0.1 and port 8080.
http://127.0.0.1:8080/
If port 8080 is not free, it uses another port:
http://127.0.0.1:52749/
http://127.0.0.1:52858/
If you need to see the web server on other machines in your local network, you can check what is your IP and use:
live-server --host=192.168.1.121
And here is a script that automatically grab the IP address of the default interface. It works on macOS only.
If you put it in .bash_profile, the live-server command will automatically launch the server with the correct IP.
# **
# Get IP address of default interface
# *
function getIPofDefaultInterface()
{
local __resultvar=$1
# Get default route interface
if=$(route -n get 0.0.0.0 2>/dev/null | awk '/interface: / {print $2}')
if [ -n "$if" ]; then
# Get IP of the default route interface
local __IP=$( ipconfig getifaddr $if )
eval $__resultvar="'$__IP'"
else
# Echo "No default route found"
eval $__resultvar="'0.0.0.0'"
fi
}
alias getIP='getIPofDefaultInterface IP; echo $IP'
# **
# live-server
# https://www.npmjs.com/package/live-server
# *
alias live-server='getIPofDefaultInterface IP && live-server --host=$IP'
I've been using filebrowser for the past couple of years and it is the best alternative I have found.
Features I love about it:
Cross-platform: It supports Linux, MacOs and Windows (+). It also supports docker (+).
Downloading stuff is a breeze. It can automatically convert a folder into zip, tar.gz and etc. for transferring folders.
You can file or folder access to every use.