it is possible to run the bot cli on a serverless microservice like architecture? Such as Aws Lambda and Azure Functions.
To install on my machine, first I need to have node/npm installed. Then I run this command:
npm i -g
It is possible to have a fully functional bot framework cli on a linux stateless environmen such as aws lambda? If so, there is any particular thing that I need to do to install it?
I know in advance that lambda limits the folders which I have access (i only can write at the /tmp folder, for instance).
Also, I have the option to attach a .zip containing the node modules folder if I want.
Any suggestions here?
did you try installing the bf cli package and run a command you'd like to run?
Related
This is a rather beginner question. Apologies for nothing more challening :)
I am running IPFS Desktop on my computer. I downloaded it via the Ubuntu Software Center. I believe it's a snap install. I am using Ubuntu 20.04
I want to be able to access some of the CLI commands for the node that is being run via the IPFS Desktop but when I enter any ipfs command in the terminal, it says command not found. etc.
If I install the ipfs cli then it runs a different node through the terminal. Am I missing something obvious here? How can I access the IPFS Desktop node through the command line?
Thanks!
Without running into distribution/package-specifics, below are two ways that should work on all systems.
Quick ad-hoc solution: point the ipfs CLI client at the node run by IPFS Desktop by passing an explicit API endpoint (ipfs --api=/ip4/127.0.0.1/tcp/5001). You can find exact address via Status_→_Advanced_→_API in WebUI provided by Desktop app.
Alternative is to set IPFS_PATH variable in your env to the directory used by IPFS Desktop, ensuring ipfs CLI tool uses the same repo as Desktop app. This is especially useful when you need to run a command that does not work over API and requires direct access the repository (like ipfs key export|rotate).
Thank you all for your answers. I believe the problem was in installing it using snap store (Ubuntu Software Center) because this changes the default path of the installations. So in effect, the desktop and cli were installed at separate paths.
I followed the installation on the IPFS site which uses the install script and that put it in the correct path.
So I re-installed only the CLI and use the webUI in place of the desktop. Along with IPFS Companion, desktop is not really needed.
But I still wanted the functionality of having the desktop run the daemon behind the scenes without having a terminal open, so I created the following service unit file to do that:
Paste the following code in the file /etc/systemd/system/ipfs.service
[Unit]
Description=IPFS Daemon
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/ipfs daemon
User=user
Restart=on-failure
[Install]
WantedBy=default.target
Then I simply ran sudo systemctl start ipfs in a terminal to get the daemon running as a service.
Thanks!
Yes IPFS should not be installed as a snap as you discovered it creates a second path. Installation is preferred by deb over appimage as the appimage limits user to only GUI interface. Another possible pitfall in the future could be the definition of "daemon" and "cluster". These are true to Unix definitions so a "daemon" is a service that manages a number of nodes on the same machine. Cluster is for multiple nodes that are physically seperated to different machines and locales. Other than that I'd say you are on the right path!
I am looking to play with apache-superset on a cloud-based ide. I have it on my local. I tried unsuccessfully to set it up on gitpod. I wanted suggestions on where can I set it up, opensource preferably not necessarily. I believe cloud9 is 1 such place, but I am looking for other options before I settle. If you've ever set it up on any such platform, even if it is on gitpod and can help me, kindly do so.
[Disclaimer: Gitpod staff]
You can indeed use Gitpod to work on apache-superset, and for that you'll just need a working configuration.
From what I can see in apache-superset's requirements, you'll need to get:
PostgreSQL (e.g. by using Gitpod's official gitpod/workspace-full-postgres Docker base image)
Redis (e.g. by installing it in a Dockerfile via sudo apt-get install)
Various Python dependencies (e.g. by running pip install . after cloning)
Various Node.js dependencies for the front-end (e.g. by running npm install)
Here is a basic configuration I wrote to achieve this:
https://github.com/jankeromnes/incubator-superset/commit/0d345a76ec8126fd1f8b9bc7b6ce4961bf3b593d
What it does is:
Create a Docker image with PostgreSQL and Redis
Once the repository is cloned, open 4 separate Terminals ("tasks"):
Redis server
Superset backend
Superset worker
Superset front-end
All dependencies will be installed automatically, and once the front-end is ready, it will automatically open in a web preview IDE side panel.
You can try it out by opening my personal fork of the apache-superset repository in Gitpod, e.g. by following this link:
https://gitpod.io/#https://github.com/jankeromnes/incubator-superset
I'm developing a bot for Telegram and I am using Up to create a Lambda function for AWS. The problem is that when I want to create the function I get an error saying:
Error: Cannot find credentials, visit https://up.docs.apex.sh/#aws_credentials for help.
How do I create the ".aws" folder and the "credentials" file? Under what folder will this be saved? Is it in the same folder I created my bot?
This is on MAC.
After installing the AWS CLI for Mac, type aws configure to initialize the credentials file for the first time.
If you have homebrew you can install awscli like this:
brew update
brew install awscli
And then use the following to configure your aws with you access id and token:
aws configure
First, you need to install AWS CLI for OSX using the following link. Refer the documentation for Install the AWS Command Line Interface on macOS for more details.
Then you need to create AWS Programmatic Access Credentials (After creating a AWS IAM User) and download the credentials. For this you need to go to the IAM section of AWS Web Console. Refer the documentation for Understanding and Getting Your Security Credentials for more details.
Then configure the credentials using the shell commands. Refer the documentation Configuring the AWS CLI for more details.
Install AWS CLI in your mac OS from link below:
[https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux-mac.html#cliv2-linux-mac-install][1]
Verify installation. Change to aws instead of aws2 incase you are using version-1
$ aws2 --version
Configure
$ aws2 configure
You need to configure your CLI before you can use it.
From
https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html
"Quick Configuration
For general use, the 'aws configure' command is the fastest way to set up your AWS CLI installation."
I tried using sudo to run a command on Heroku. Then I get a message that I cannot use the sudo command on Heroku. My real question is: How can I run a command with root privilege on Heroku, because it is required for some of the commands I'm trying to run?
You cannot run as root on a Heroku Dyno, as Dynos are effectively containers, isolated from the host system. However, you should be able to install most packages via Buildpacks, either via first party supported buildpacks, thirdparty buildpacks, or via heroku-buildpack-apt. Attempting to alter any system files, will likely either not work, or will have unintended consequences.
I am installing AWS Autoscaling tools on linux redhat, But unfortunately the as-cmd command is not working.
I am getting this error :
-bash: as-cmd: command not found
How to resolve the error ?
Any lead is appreciated
To Answer your question:
run below:
$ updatedb
$ locate as-cmd
This should provide you the path of the command like /usr/bin/as-cmd. Either you should use this complete path while running the command OR you need to update your $PATH variable to include this path. Google if you want to know how to update PATH variable.
Now, some suggestions:
You should not use as-cmd anymore. Please use AWS CLI. Here is the AWS CLI relevant autoscaling commands
The reason being, as-cmd is not maintained by Amazon anymore and all the old CLI features have been exported to AWS CLI. AWS CLI is a one stop shop for all the AWS Services unlike older CLIs where you had to install a separate CLI for individual services.
AWS CLI provides output in JSON format which is much more easier to parse.
BESIDES, You don't have to play with CLI for autoscaling. Now, you can do the same job via AWS Console.