he used this tutorial: http://blog.urbaninsight.com/2012/10/31/installing-nodejs-centos-55-server
and apparently it has gone well, 100% good, no errors.
now i am here: http://www.nodebeginner.org/
I can't fide any instructions on what node modules i need to put on my server so I am guessing ... I downloaded the latest node source code from the node site and have put the lib folder into my public_html.
I now have made a hello.js which looks like this:
var http = require("lib/http.js");
http.createServer(function(request, response) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.write("Hello World");
response.end();
}).listen(8888);
and 'as i expected' my guess is utter poop.. when I go to mysite.com:8888 i get Oops! Google Chrome could not connect to blaa blaa blaa
I have to think hard of how/what exactly i am trying to ask here...ok, I keep reading tutorials about doing things locally but can find nothing for online, to be
honest after my host finished installing stuff I expected to visually see some new .js file(s) sitting on the server (http.js? or something). I actually can't even figure out how to ask google on this one...
I can look through the tutorials at the code and see that it looks like very easy javascript (my favourite language, better than english), but its like i'm missing the part where i need to upload or connect to the frame work like when you use jquery; you can't just write jquery code cause the browser will be like what the hell is $? first you must do something like:
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
1.use a server that can interpret/run node (done)
2.??!
3.write simple code
---------------update-----------------------------
[root#user node-latest-install]# curl https://npmjs.org/install.sh | sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7882 100 7882 0 0 2835 0 0:00:02 0:00:02 --:--:-- 7697k
tar=/bin/tar
version:
tar (GNU tar) 1.15.1
install npm#latest
fetching: http://registry.npmjs.org/npm/-/npm-1.2.18.tgz
0.10.3
1.2.18
cleanup prefix=/root/local
find: /root/local/lib/node: No such file or directory
find: /root/local/lib/node: No such file or directory
All clean!
/root/local/bin/npm -> /root/local/lib/node_modules/npm/bin/npm-cli.js
npm#1.2.18 /root/local/lib/node_modules/npm
It worked
[root#user node-latest-install]# cd ~
[root#user ~]# ls -l
total 548
drwxr-xr-x 5 root root 4096 Apr 7 04:03 local
drwx------ 5 root root 4096 Apr 4 19:37 Maildir
drwxr-xr-x 10 root root 4096 Apr 7 04:04 node-latest-install
drwxr-xr-x 2 root root 4096 Apr 7 04:04 tmp
-rw-r--r-- 1 root root 536584 Apr 4 19:38 virtualmin-install.log
[root#user ~]# ls -l ~/local
total 12
drwxr-xr-x 2 root root 4096 Apr 7 04:04 bin
drwxr-xr-x 4 root root 4096 Apr 7 04:03 lib
drwxr-xr-x 3 root root 4096 Apr 7 04:03 share
[root#user ~]#
I've also changed to require("http") and it still is giving me the same 'oops' error
To answer your main question about programming in node in general, you seem to be missing npm
1) First things first, install npm using
curl http://npmjs.org/install.sh | sh
Once you have npm, programming in node becomes much easier.
2) In your file, change
var http = require("lib/http.js");
to
var http = require("http");
Everything should work fine then.
Related
(ubuntu 18.04)
I'm attempting to extract an odbc driver from a tarball and following these instructions with command:
tar --directory=/opt -zxvf /SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux.tar.gz
This results in the following output:
root#08ba33ec2cfb:/# tar --directory=/opt -zxvf SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux.tar.gzSimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/GoogleBigQueryODBC.did
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/release-notes.txt
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/Simba Google BigQuery ODBC Connector Install and Configuration Guide.pdf
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/OEM ODBC Driver Installation Instructions.pdf
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/simba.googlebigqueryodbc.ini
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/odbc.ini
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/odbcinst.ini
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/SimbaODBCDriverforGoogleBigQuery32_2.4.6.1015.tar.gz
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015.tar.gz
The guide linked to above says:
The Simba Google BigQuery ODBC Connector files are installed in the
/opt/simba/googlebigqueryodbc directory
Not for me, but I do see:
ls -l /opt/
total 8
drwxr-xr-x 1 1000 1001 4096 Apr 26 00:39 SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux
And:
ls -l /opt/SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/
total 52324
-rwxr-xr-x 1 1000 1001 400 Apr 26 00:39 GoogleBigQueryODBC.did
-rw-rw-rw- 1 1000 1001 26688770 Apr 26 00:39 SimbaODBCDriverforGoogleBigQuery32_2.4.6.1015.tar.gz
-rw-rw-rw- 1 1000 1001 26876705 Apr 26 00:39 SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015.tar.gz
drwxr-xr-x 1 1000 1001 4096 Apr 26 00:39 docs
drwxr-xr-x 1 1000 1001 4096 Apr 26 00:39 setup
I was specifically looking for the .so driver file. All the above is on a docker container. I tried extracting the tarball locally on Ubuntu 18.04 (Same as my Docker container) and when I use Ubuntu desktop gui to extract by double clicking the tar.gz file and then clicking 'extract', I do indeed see the expected files.
It seems my tar command (tar --directory=/opt -zxvf /SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux.tar.gz) is not extracting the tarball as expected.
How can I extract the contents of the tarball properly? The tarball in question is the linux one on this link.
[edit]
Adding screens of contents of the tarball per comments. I had to click down two levels of nesting to arrive at 'stuff':
The instructions you linked to do not match the contents of the file I found from here. The first .tar.gz contains two other .tar.gz files. I looked into the 64 bit one and it has:
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/SimbaBigQueryODBCMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/ODBCMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/SQLEngineMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/DSMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/DSCURLHTTPClientMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/third-party-licenses.txt
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/libgooglebigqueryodbc_sb64.so
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/cacerts.pem
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/EULA.txt
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/Tools/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/Tools/get_refresh_token.sh
Your .so is in the lib directory. Based on the instructions it looks like you need to extract this file (or the 32 bit if appropriate) and rename, in this case SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015 to simba/googlebigqueryodbc. The tar command is doing what it is told but the instructions are way off.
I'm unsure about some small obscure details that I worry will have large effects. On my Raspbian Debian 11 running on a Raspberry Pi, sudo apt update && sudo apt full-upgrade only updates my libxml2 library to version 2.9.10, no further. However, I need version 2.9.14 for the security patches contained within. With help from this question (thank you Esther!), I decided to compile version 2.9.14 from source. Everything went well, and the library was placed into /usr/local/lib. I then updated ldconfig by following this answer. However, although that should have made Debian use the new 2.9.14 version, apt-cache policy libxml2 still shows:
libxml2:
Installed: 2.9.10+dfsg-6.7+deb11u2
Candidate: 2.9.10+dfsg-6.7+deb11u2
Version table:
*** 2.9.10+dfsg-6.7+deb11u2 500
500 http://raspbian.raspberrypi.org/raspbian stable/main armhf Packages
100 /var/lib/dpkg/status
I think I know why this is. If I was installing a never-before-seen library, everything might have worked properly. However, since I now have a second libxml2 library without removing the 1st, any time the system needs to use libxml2, the search first reaches /usr/lib/arm-linux-gnueabihf where the old libxml2 is, so the system finds the old version, is satisfied, and so stops searching before finding the new version.
For context before I continue:
(link to below but in color: https://i.stack.imgur.com/OJLJW.png)
pi#fuelightcontrol:~ $ cd /usr/lib/arm-linux-gnueabihf/
pi#fuelightcontrol:/usr/lib/arm-linux-gnueabihf $ ls -l | grep libxml2
lrwxrwxrwx 1 root root 17 May 15 14:58 libxml2.so.2 -> libxml2.so.2.9.10
-rw-r--r-- 1 root root 1510312 May 15 14:58 libxml2.so.2.9.10
pi#fuelightcontrol:/usr/lib/arm-linux-gnueabihf $ cd /usr/local/lib
pi#fuelightcontrol:/usr/local/lib $ ls -l
total 12120
drwxr-xr-x 3 root root 4096 Jun 14 18:17 cmake
-rw-r--r-- 1 root root 7145994 Jun 14 18:17 libxml2.a
-rwxr-xr-x 1 root root 944 Jun 14 18:17 libxml2.la
lrwxrwxrwx 1 root root 17 Jun 14 18:17 libxml2.so -> libxml2.so.2.9.14
lrwxrwxrwx 1 root root 17 Jun 14 18:17 libxml2.so.2 -> libxml2.so.2.9.14
-rwxr-xr-x 1 root root 5242072 Jun 14 18:17 libxml2.so.2.9.14
drwxr-xr-x 2 root root 4096 Jun 14 18:17 pkgconfig
drwxr-xr-x 3 root root 4096 Jun 13 21:43 python3.9
-rw-r--r-- 1 root root 205 Jun 14 18:17 xml2Conf.sh
pi#fuelightcontrol:/usr/local/lib $
The question is, what would be the best way to go about fixing the problem of the old version still being used by apt-cache policy libxml2 and other programs? I could:
Just delete /usr/lib/arm-linux-gnueabihf/libxml2.so.2.9.10 (the old one) and its symbolic link, so the system keeps searching past that point and eventually finds /usr/local/lib/libxml2.so.2.9.14 (the new one). However, something feels... off about having my libraries scattered around in different directories. My gut tells me to keep them in one place. Also, see paragraph below the next list item.
I could delete /usr/lib/arm-linux-gnueabihf/libxml2.so.2.9.10 (the old one) and its symbolic link, then move the new version into /usr/lib/arm-linux-gnueabihf to replace the old version. However, there's more libxml2 related files and 1 more symbolic link in /usr/local/lib that are not present in /usr/lib/arm-linux-gnueabihf. Do I need to move those too, or should I just move libxml2.so.2.9.14 and one (both?) of the symbolic links? If only 1 link, which?
Should I delete the files left behind after I move the required ones over? Also, see paragraph below.
What concerns me about deleting anything is if some other script comes looking for libxml2.2.9.10, can't find it, and fails. I don't know how to tell the rest of the programs that libxml2's filename is different now. I suppose both options 1 and 2 might work, but is one option a cleaner, smarter idea? I'm trying to save myself some work in the future.
Sorry this is such a small silly question. Thank you for your help!
Edit: After making backups of both directories, I tried option 1 first, then option 2. Neither changed the output of apt-cache policy libxml2 - it still says I have libxml2 2.9.10 installed, even though I deleted /usr/lib/arm-linux-gnueabihf/libxml2.so.2.9.10 and its symbolic link, rebooted, and ran sudo apt update
Here's how I updated ldconfig (same as the second link), to clear up loose ends. The link to /usr/local/lib was done for me already, which was nice.
Link to screenshot of below but in color: https://i.stack.imgur.com/7w6XR.png
pi#fuelightcontrol:/etc $ ls -l ld.so.conf
ld.so.conf ld.so.conf.d/
pi#fuelightcontrol:/etc $ cat ld.so.conf
include /etc/ld.so.conf.d/*.conf
pi#fuelightcontrol:/etc $ ls -l ld.so.conf.d
total 16
-rw-r--r-- 1 root root 12 Dec 1 2021 00-vmcs.conf
-rw-r--r-- 1 root root 109 May 14 2019 arm-linux-gnueabihf.conf
-rw-r--r-- 1 root root 41 Jun 25 2018 fakeroot-arm-linux-gnueabihf.conf
-rw-r--r-- 1 root root 44 Jun 14 19:08 libc.conf
pi#fuelightcontrol:/etc $ cat ld.so.conf.d/libc.conf
# libc default configuration
/usr/local/lib
pi#fuelightcontrol:/etc $ sudo ldconfig
pi#fuelightcontrol:/etc $ sudo ldconfig /usr/local/lib
pi#fuelightcontrol:/etc $ sudo ldconfig -n /usr/local/lib
pi#fuelightcontrol:/etc $ cat ld.so.conf.d/00-vmcs.conf
/opt/vc/lib
pi#fuelightcontrol:/etc $ cat ld.so.conf.d/arm-linux-gnueabihf.conf clear
# Multiarch support
/usr/local/lib/arm-linux-gnueabihf
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf
cat: clear: No such file or directory
pi#fuelightcontrol:/etc $ cat ld.so.conf.d/fakeroot-arm-linux-gnueabihf.conf
/usr/lib/arm-linux-gnueabihf/libfakeroot
pi#fuelightcontrol:/etc $
I have added the following to the file /etc/sudoers using the visudo command:
nick ALL=(ALL:ALL) ALL
But when I log in as nick and attempt something like mkdir .ssh I get:
mkdir: cannot create directory ‘.ssh’: Permission denied
Likewise, I cannot save files I have edited.
Running ls -la from the home directory gives me:
drwxr-xr-x 5 nick nick 4096 Apr 7 19:07 .
drwxr-xr-x 3 root root 4096 Apr 7 17:32 ..
-rw-r--r-- 1 nick nick 220 Aug 31 2015 .bash_logout
-rw-r--r-- 1 nick nick 3771 Aug 31 2015 .bashrc
drwx------ 2 nick nick 4096 Apr 7 18:29 .cache
drwxr-xr-x 2 root root 4096 Apr 7 19:07 .nano
-rw-r--r-- 1 nick nick 675 Aug 31 2015 .profile
Which if I'm not mistaken is showing that I have no write access to anything. (Correct me if I'm wrong. I'm only passingly familiar with UNIX permissions.)
Why can't this user do anything despite being given full permissions in sudoers?
UPDATE:
This problem fixed itself. I do not know what the problem was but it was no longer a problem when I logged on a couple days later.
For the record, I was attempting to configure a fresh DigitalOcean server running Ubuntu 15.10 x64. My local computer is a MacBook running El Capitan.
My guess is that the remote server restarted or somehow otherwise incorporated the change automatically in the interim. I had already tried running sudo reboot producing no results, so I'm still not sure how this could be.
I was also experiencing some local WiFi connection dropping at the time but as my SSH connection seemed to be operational I'm not sure if this could be related.
I'm also not an expert to Linux, but to me it seems like you have to use sudo mkdir .ssh instead of mkdir .ssh. You allowed your user to behave like root(who has rights to write to directory), but for doing that you have to use sudo command.
Here is the simple explanation of how it works(with pictures): https://www.garron.me/en/linux/visudo-command-sudoers-file-sudo-default-editor.html
Here is the serious documentation: https://help.ubuntu.com/community/Sudoers
since a while i am trying to reach something that doesn't work out for me so far.
With nodejs, i like to run a interactive sh-command and work with the sh-command output after the command has exited. i like to write a yieldable generator-function that wraps the running of the interactive shell command and returns the output of the shell command.
Approach 1: shelljs
shelljs
I had some success with shelljs, but at some point it wont run further.
Question 1: is it possible to get shelljs to the point where i can inherit stdio and make the shelljs function yieldable?
Approach 2: child_process.spawnSync
child_process.spawnSync
at last i discovered child_process.spawnSync and was happy that, at least i can run interactive sh-commands without problems with options: { stdio: 'inherit' }
but i haven't found out how to get back the output of child_process.spawnSync.
Question 2: How to wrap spawnSync into a generator function that returns the child_process's output?
Approach 3: co-child-process
i also tried co-child-process.
it seems to run, but not interactive with stdio. there is a issue regarding this, i dont really understand.
Question 3: could someone explain me/ post a example how co-child-process will work with stdio inherit.
Approach 4: promisify child_process.spawn() with bluebird
i opened an issue on bluebird if child_process.spawn() is promisifiable
So my question at all. Can someone post me an example of how to run a interactive shell command that can be wrapped in a yieldable generator function that returns the output of the shell command? i am open for new approaches.
I created a npm module which is available on github where you can fork it and contribute.
thx in advance.
I found the following which works on v5.4.1 . In the docs NodeJS Child Process it mentions the option encoding which has a default of 'buffer'. If you set this option to 'utf8', then instead of a buffer you get a string back with the results. You can get a string back from spawnSync because it is synchronous and blocks execution until the command completes. Here's a working example of a script which does an 'ls -l /usr' command and gets the output as a string object:
#!/usr/bin/env node
var cp = require('child_process');
var ls = cp.spawnSync('ls', ['-l', '/usr'], { encoding : 'utf8' });
// uncomment the following if you want to see everything returned by the spawnSync command
// console.log('ls: ' , ls);
console.log('stdout here: \n' + ls.stdout);
When you run it you get the following:
stdout here:
total 68
drwxr-xr-x 2 root root 36864 Jan 20 11:47 bin
drwxr-xr-x 2 root root 4096 Apr 10 2014 games
drwxr-xr-x 34 root root 4096 Jan 20 11:47 include
drwxr-xr-x 60 root root 4096 Jan 20 11:47 lib
drwxr-xr-x 10 root root 4096 Jan 4 20:54 local
drwxr-xr-x 2 root root 4096 Jan 6 01:30 sbin
drwxr-xr-x 110 root root 4096 Jan 20 11:47 share
drwxr-xr-x 6 root root 4096 Jan 6 00:34 src
The docs tell you what you can get back on the object in addition to stdout . If you want to see all the properties on the return object, uncomment the console.log (Warning: there's a LOT of stuff :) ).
I have read the Theos/Setup on the iPhoneDev Wiki.
I have installed Theos into /var/theos (private/var/theos) and have copied in the iPhone8.1.sdk into /var/theos/sdks/iPhone8.1.sdk:
iPhone:/var/theos/sdks root# ls -al
total 0
drwxr-xr-x 3 root admin 102 Nov 7 08:11 ./
drwxr-xr-x 9 root admin 374 Nov 7 07:58 ../
drwxrwxr-x 5 root admin 306 Nov 7 08:01 iPhoneOS8.1.sdk/
I have fixed the issues with perl/rsync not being compiled for arm64 by following the instructions
I created a tool:
$THEOS/bin/nic.pl
....
iPhone:~/Work/test root# ls
Makefile control main.mm theos#
However, when I make, I get the following error:
iPhone:~/Work/test root# make
/var/theos/makefiles/common.mk:116: *** The "iphone" target is not supported on the "iphone" platform. Stop.
What am I doing wrong? Or is this a problem with the 8.1 sdk?
Following the article at http://sharedroutine.com/?p=11 got it working for me.
I symlinked /var/theos/makefiles/platform/Darwin-arm to /var/theos/makefiles/platform/Darwin-arm64 and forgot to symlink /var/theos/makefiles/targets/Darwin-arm to /var/theos/makefiles/targets/Darwin-arm64.
ln -s /var/theos/makefiles/targets/Darwin-arm /var/theos/makefiles/targets/Darwin-arm64
ln -s /var/theos/makefiles/platform/Darwin-arm /var/theos/makefiles/platform/Darwin-arm64
Your paths may be different.