I have very bad internet, so I want to download the api(mongodb, react, nodejs) I need to work on a project on a local computer, tell me if this can be done?
You could probably play with "npm cache add some-package.tar.bz2" or with npm-proxy but it will probably require too much effort (or will not resolve all issues).
Alternative way would be to setup proxy server(for example squid) to keep once downloaded files localy at your server/computer.
This way you configure your system (and tools) to use yours proxy server.
So when vagrant, apt, npm, grunt or some other tool need some file from internet during the build it will download it only once and get it out of the cache of proxy server during subsequent requests.
majority of tools favour environment variables HTTP_PROXY and HTTPS_PROXY.
So you could setup docker container, virtual machine or just service (squid has windows binaries as well) and configure your system to use proxy server, i.e. add environment variables either globaly or in bash file for build process only.
Lets suppose you configured your squid at docker container with IP address 172.17.0.34. then your build script would look like:
#!/bin/bash
export HTTP_PROXY=172.17.0.34:3128
export HTTPS_PROXY=172.17.0.34:3128
npm install
For it to take global effect you could place these two lines into your /etc/environment file:
HTTP_PROXY=172.17.0.34:3128
HTTPS_PROXY=172.17.0.34:3128
Related
I made a Vue app with Bootstrap-Vue, Express(nodejs) and MySQL. I'm using vue-cli and It's currently in development mode. I've created a SPA(server and client in different folders), and I'm compiling with vscode terminal using:
cd client
npm run serve
and
cd server
node index.js
My problem is: I don't have a domain because it's only for personal use(and I don't have money), and to open the vscode and doing the rotine takes 20-60 seconds. Is there an alternative and quickly way to run my vue app?
I can think of a couple of things you can do.
1) Get a free domain and free hosting
As I mentioned in the comments, you can get a free domain at freenom.com, and host it for free with render.com. This has some pros and cons to it.
Pros:
It's free.
You can access it from anywhere.
No need to setup every time, just enter the URL.
Cons:
You probably won't get to choose the domain's extention. It'll probably be a .tk domain or something not very well known.
I believe that you need to renew it annually, but that's with any domain.
Anyone an access it, though it's not like everyone will know about it.
Needs an internet connection, but this isn't a problem if your app already needs internet access to function.
You can also host it with Github. Here's instructions on how to do that, and here's instructions to set up Github pages.
See Deploying a Node Express App or Deploying a Vue.js App for instructions on how to set up hosting on render.com
2) Automate what you are doing now
Typing takes time, and you can create a batch file to run those commands for you. Depending on what OS you are on (I'm doing this for windows), you can create a file, e.g. OpenApp.bat and place inside what you are already doing:
cd C://ABSOLUTE_PATH_TO_CLIENT
npm run serve
cd C://ABSOLUTE_PATH_TO_SERVER
node index.js
start localhost:8080 or whatever the path is
Then just double click it and it'll run these tasks for you. I haven't tested this idea yet so not sure if it'll work.
3) Build your app
A third option would be to build your app, then serve it. This would eliminate the time npm run serve takes, and you can host it instead with serve.
Install serve:
npm install -g serve
...and build your app:
npm run build
...and serve the app:
serve -s dist
It should instantly serve your app without any long processing time.
You can create a batch file to do this also (again, I'm not sure if it'll work):
cd C://ABSOLUTE_PATH_TO_CLIENT
serve -s dist
cd C://ABSOLUTE_PATH_TO_SERVER
node index.js
start localhost:5000 or whatever the path is
This should be faster than option 2...but editing your app requires it being re-built each time to see the changes.
I have a Vue Cli 3 app which, when built, creates a bundle of web components in the "dist" directory.
I'm looking for a way to be able to browse the files within the "dist" directory when running npm run serve, which starts the webpack dev server.
When I do this now (i.e., something like browse to http://localhost:8083/dist/component.js), I'm simply presented with the index.html file found in the public directory.
How can I configure via the vue.config.js file the ability to have the devserver serve up files in the "dist" directory?
devServer is intended to provide development environment with configurations to apply certain loaders, plugins, etc. What you are looking for is a way to serve locally hosted files as a working application. These are two different purposes and I would not recommend adjusting devServer config for such purpose.
There are easy ways to serve static files on local machine.
One of the simplest is to use live-server, serve or similar.
In order for it to work with live-server just few steps are required:
1) Install
npm install -g live-server
2) In terminal navigate to the folder where static files are located (e.g. project-folder/dist/
3) Run live-server command.
This will open a browser tab with index.html as an entry point and will simulate a webserver on a local machine. There are many more options available in docs.
But this will serve the purpose and will not interfere with devServer purpose.
I would like to create a private npm repo on our nexus.
So i guess i need to take the current node_modules folder on my machine and put it in Nexus, right?
I cant proxy npm, because on our jenkins machine we don't have internet access.
So how do i put all my node modules (lots of folders) onto Nexus?
and in what structure and format?
See https://github.com/DarthHater/nexus-repository-import-scripts for uploading a lot of files into NXRM3.
If that doesn't work for you, likely you can modify that script for your needs.
I installed apache httpd on my linux vm and wanted to start it's service. BUt I'm getting error (13)Permission denied. Error retrieving pid file run/httpd.pid I realised that I do not have this file. Not even a var directory. Any solutions for this? Pardon me, this is my first time touching servers.
I installed the apache like this:
gzip -d httpd-2.2.21.tar.gz
tar xvf httpd-2.2.21.tar
./configure --prefix=/home/Hend/Desktop/Server
make
make install
You have several alternatives for this:
Install apache in user directory, run as non-root user
This is the way you started doing that. But then you'll have to:
Add some customizations to the start script, or at least pass it enough environment variables to tell him where configuration / pidfile / etc. are
Modify the whole apache configuration, since the default uses directories to which you don't have access. For example, you should put your DocumentRoot somewhere else thant /var/www
Run the server on a non-standard port. Since unprivileged users cannot run services on ports lower than 1024, you must run apache on another port, such as 8000 instead of 80. But this way, all your URLs will look like http://example.com:8000 instead of http://example.com.
Install apache from sources, into /usr/local
You can install apache in the default path for non-part-of-distro stuff, that is /usr/local instead of /usr/. That is, use --prefix=/usr/local/ when running configure.
This way, things should be much simpler. In any case, you'll have to run the webserver from root, and configure it to change user only after socket is opened.
Install apache from sources, into /usr/
You can also install apache in its default location, usint --prefix=/usr/. This way things should be much simpler, it should install init scripts in the usual location /etc/init.d/apache2 or /etc/init.d/httpd, configuration in /etc/apache2 etc.
Beware that doing this all the apache installed files will conflict with the ones of the version provided by your linux distribution!
Install apache from your distribution package manager
A part from the case in which you want particular setups (for example with non-standard patches), particular non-packaged versions (not recommended, since usually versions packaged with distros are guaranteed to be stable, others are not).
Benefits of doing this:
Avoid huge setup + configuration process to make it work
Versions from your distro should be "guaranteed" to be stable and tested with all the other programs shipped with it. Not always the latest version is better.
Each time a new release is updated (or more importantly, there is a security update), you can upgrade it semi-automatically by running a single upgrade command, without worrying about things going wrong during update.
This way the whole installation is just matter of a couple commands.
For example, on debian:
apt-get install apache2
On fedora:
yum install httpd
etc.
Then, if the service is not already started by package manager, you can start it with
/etc/init.d/apache2 start
or
/etc/init.d/httpd start
Job done. Now just put stuff in /var/www/ (or equivalent directory, depends on distro) and see it through you web server.
You have to start apache as root
Have you read the docs in the source distribution?
ie INSTALL
less INSTALL
For complete installation documentation, see [ht]docs/manual/install.html or
http://httpd.apache.org/docs/2.2/install.html
$ ./configure --prefix=PREFIX
$ make
$ make install
$ PREFIX/bin/apachectl start
As part of our product release we ship Apache HTTP Server binaries that we have compiled on our (UNIX) development machine.
We tell our clients to install the binaries (on their UNIX servers) under the same directory structure that we compiled it under. For some clients this is not appropriate, e.g. where there are restrictions on where they can install software on their servers and they don't want to compile Apache themselves.
Is there a way of compiling Apache HTTP Server so its installation location(s) can be specified dynamically using environment variables ?
I spent a few days trying to sort this out and couldn't find a way to do it. It led me to believe that the Apache binaries were hard coding some directory paths at compilation preventing the portability we require.
Has anyone managed to do this ?
I think the way to do(get around) this problem is to develop a "./configure && make" script that your client uses to install, specify and compile the binaries. That would offcourse require that the client has all the source-code installed on his server or you can make it available on an NFS share.
If you are compiling Apache2 for a particular location but want your clients to be able to install it somewhere else (and I'm assuming they have the same architecture and OS as your build machine) then you can do it but the apachectl script will need some after-market hacking.
I just tested these steps:
Unpacked the Apache2 source (this should work with Apache 1.3 as well though) and ran ./configure --prefix=/opt/apache2
Ran make then sudo make install to install on the build machine.
Switch to the install directory (/opt/apache2) and tar and gzip up the binaries and config files. I used cd /opt/apache2; sudo tar cf - apache2 | gzip -c > ~/apache2.tar.gz
Move the tar file to the target machine. I decided to install in /opt/mynewdir/dan/apache2 to test. So basically, your clients can't use rpm or anything like that -- unless you know how to make that relocatable (I don't :-) ).
Anyway, your client's conf/httpd.conf file will be full of hard-coded absolute paths -- they can just change these to whatever they need. The apachectl script also has hard coded paths. It's just a shell script so you can hack it or give them a sed script to convert the old paths from your build machine to the new path on your clients.
I skipped all that hackery and just ran ./bin/httpd -f /opt/mynewdir/dan/conf/httpd.conf :-)
Hope that helps. Let us know any error messages you get if it's not working for you.
I think the way to do(get around) this problem is to develop a "./configure && make" script that your client uses to install, specify and compile the binaries. That would offcourse require that the client has all the source-code installed on his server or you can make it available on an NFS share.
Not to mention a complete build toolchain. These days, GCC doesn't come default with most major distributions. Wouldn't it be sane to force the client to install it to /opt/my_apache2/ or something like that?
#Hissohathair
I suggest 1 change to #Hissohathair's answer.
6). ./bin/httpd -d <server path> (although it can be overridden in the config file)
In apacheclt there is a variable for HTTPD where you could override to use it.