I have just upgraded my MacPro with Mountain Lion to Mavericks 10.9 and got the problem with SSH that I can not use my Terminal any more. It just hangs there without any message ...
It seems that there is a problem with the Maximum Transmission Unit (MTU) in the latest version of SSH which is included in the new Mac OS X.
There is no solution so far for the problem but this trick work around is working for me which could work for your case also:
Simply create a new ~/.ssh/config file and add this line to it:
$ vi ~/.ssh/config
MACs hmac-md5,hmac-sha1,hmac-ripemd160
You're all set. Enjoy your new Mavericks!
Tuesday, October 29, 2013
Thursday, September 26, 2013
How to compile iOS code for iOS 6 in Xcode 5
Xcode 5 has been introduced with a lot
of changes including the support for iOS 7. Even though we do not
want to stick with the old iOS versions, there is a transition time
for us to upgrade our apps to the new SDK 7, and till then you may
want to make builds for the old iOS versions using the new Xcode 5.
This blog post provides some simple steps to build your iOS app in
multiple iOS SDKs using Xcode 5
Back-up
the old SDKs
Before upgrading to Xcode 5, remember
to back-up your old Xcode to be used later (let simply rename it to
be Xcode4.app), otherwise it will be overwritten. If you forgot to do
that, you will need to re-download the old version here,
then rename, copy the Xcode.app into your local place to refer to
later (eg: /Applications/Xcode4.app)
Setting things up
After getting the Xcode 5 installed on
your Mac, the Applications directory could typically look like this
Now go to your old Xcode4.app to copy
the SDK over to the new one, something like this:
$ cp
/Applications/Xcode4.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS
Or you may simply create a link to your
old SDK like this:
$ ln -s
/Applications/Xcode4.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
/Applications/Xcode4.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
Now in your Xcode 5 >> Build
Settings >> Base SDK you can decide which SDK you want to use
for building your app.
Downloading the old simulator(s)
If you forgot to back-up your old Xcode
before upgrading, you still can download the old simulator by going
to Xcode >> Preferences >> Download
Monday, September 16, 2013
Five things to know about IBM MessageSight - Internet of Things appliance
The Internet is no longer a global
network just for computers but is becoming an environment for diverse
devices to join. Preluded by mobile, billions of smart devices are
instrumenting our world today. They are controllers, sensors, meters,
gauges, switches, scanners, radio frequency identification (RFID) and
supervisory control and data acquisition (SCADA) systems and so on,
which are addressable with network-connected embedded
microprocessors. By 2020, the number of devices connected to the
global network is expected to be 30 billion, according to ABI
Research. Those devices are going to publish data, consume data
or both, and they will need to responsively interact with each other
and with applications through an appropriate protocol to perform
tasks without human involvement.
Aside from the other two well-known
messaging protocols—Advanced Message Queuing Protocol (AMQP) and
Simple (or Streaming) Text Oriented Messaging Protocol (STOMP)—the
Message Queue Telemetry Transport (MQTT) protocol seems to be
a very good fit for this need because it's designed to be lightweight
and less resource-consuming (network bandwidth, power) while also
attempting to ensure reliability with some assurance of delivery.
Preparing for the emerging Internet of
Things, in April 2013 IBM announced IBM
MessageSight, which is a 2U appliance-based messaging server
built on MQTT technology. MessageSight is optimized to address the
massive scale requirements of the machine-to-machine (M2M) and mobile
use cases and designed to handle and route a tremendous volume of
messages among diverse types of devices reliably and securely.
Below are five key aspects of
MessageSight and details on how the appliance could perform on
each.
1.
Scalability and performance
Built
upon the MQTT messaging protocol, which is faster and requires less
bandwidth and power than traditional HTTP(s), IBM MessageSight is
well-suited with tags and sensors for mobile devices and other
“things” that typically have low power and low communication
bandwidth capabilities. Also, the high-scale, asynchronous
publish/subscribe with event-oriented paradigm could provide
responsive interaction, which turns into better user experience and
better scalability.
One
MessageSight appliance can serve up to a million devices connected
concurrently and handle the throughput of up to 13 million
nonpersistent messages per second with predictable latency in
microseconds under load. That is an impressive number.
2.
Reliability
If
high availability (HA) and disaster recovery ability are required,
two MessageSight appliances could be easily configured to an
HA-enabled mode to act as an HA pair of nodes, one to be the primary
node (the appliance that is processing messages) and the other to be
the standby node (the appliance to which the primary node is
replicated). With HA enabled, the messaging services can withstand an
outage of an appliance and continue to provide messaging services.
At
the message delivery level, since MessageSight fully supports MQTT
protocol, it consequently supports three qualities of service options
for delivering messages between clients and servers. This allows the
delivery assurance of a particular message to be flexibly achieved as
needed.
3.
Security
There
are three main aspects to security in MessageSight: transport level
security, authentication and authorization.
MessageSight
controls transport level security and authentication
settings using a security profile associated with an endpoint to
define the security operations applied to a message flow. Besides
protecting the message content being transferred, configuring the
appropriate transport level also helps to avoid sending
authentication credentials that are not encrypted.
The
authentication
supports both local user stores and external Lightweight Directory
Access Protocol (LDAP) servers, which gives users more flexibility in
building up a security plan.
IBM
MessageSight implements a policy-based authorization mechanism
to allow clients to connect and use messaging actions (connection and
messaging policies). A modern policy-based security approach is
comprised of a cohesive set of different policies, which helps
MessageSight to efficiently achieve security compliance.
Supporting
Secure Sockets Layer (SSL) and Transport Layer Security (TLS)
protocols that only run signed, encrypted firmware images provided by
IBM, encrypted flash storage media make MessageSight secure enough to
be used for demilitarized zone (DMZ) environments and placed at the
edge of an enterprise to interface with the external world.
4.
Integration ability
As
a full-featured messaging appliance, the ability to integrate with
other systems is a key feature of IBM MessageSight.
By supporting the well-known messaging
protocols MQTT (MQTT over Transmission Control Protocol/Internet
Protocol [TCP/IP], MQTT over WebSockets) and Java Message Service
(JMS), the appliance is well-suited with both publish/subscribe
(topic-based) and point-to-point (queue-based) messaging models and
can be widely integrated with other systems like Java-based systems,
rich HTML5-based applications and so on.
MessageSight
can extend and connect to WebSphere MQ infrastructures and supports
connectivity to IBM
Integration Bus by using MQ connectivity. Options appropriate for
this are to use multiple queue managers to handle the messages or
preserve the message order by using a single queue manager.
5.
Developer-friendly
Built
on the open MQTT, MessageSight supports MQTT client applications and
libraries for a variety of platforms such as:
- MQTT over TCP/IP: MQTT C client; MQTT client for Java, Android and iOS
- MQTT over WebSockets: MQTT client for JavaScript
- JMS: IBM MessageSight JMS client
- PhoneGap MQTT plug-ins with JavaScript application programming interface (API) for use with IBM Worklight, Apache Cordova and Adobe PhoneGap
If
you want to play around with it to see how it works from a
developer's perspective, you can quickly get a version of
MessageSight developer here.
It usually takes less than one hour to have everything set up and
running and to start experiencing the virtual appliance.
As
part of the IBM
MobileFirst
portfolio, IBM MessageSight could play a very important
role in helping organizations to transform, adapt and catch up to new
businesses.
Detailed information here
Sunday, June 16, 2013
Using IBM HTTP Server for reverse proxying: SSL0266E: Handshake Failed, Could not establish SSL proxy connection.
Oops!
And more:
SSL0234W: SSL Handshake Failed, The certificate sent by the peer has expired or is invalid ....
Certificate validation error during handshake, last PKIX/RFC3280 certificate validation error was GSKVAL_ERROR_NO_CHAIN_BUILT blah blah blah ...
That's what I'd got while trying to setup a reverse proxy using IBM HTTP Server (IHS) to a target web server which installed GeoTrust SSL cert, had taken me a nice Friday evening :(. Basic Apache version of the HTTP server works fine. If any of you run into this problem, the following quick tips would make your day a beautiful one.
- Handshake failed, so it should be problem with setting up of your cert
- Basic Apache version works just fine, so it must be something related to mod_ibm_ssl which IHS uses with more stringent validation (Apache uses mod_ssl)
I came out with a quick trying to simply add the target machine's root CA cert to my IHS cert store (the .kdb file).
- Download the root CA cert of the cert being used by the target machine. In my case, it was GeoTrust (and I was struggling to figure out what should I use in the long list provided by GeoTrust which was confusing: http://www.geotrust.com/resources/root-certificates/ . It turns out that the Root 2 is the right one to go with: http://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem)
- Use the ikeyman tool to open the .kdb file being used by your IHS and import (retrieve) the root CA you just downloaded.
- Restart your IHS and you're all set.
Hope this helps.
And more:
SSL0234W: SSL Handshake Failed, The certificate sent by the peer has expired or is invalid ....
Certificate validation error during handshake, last PKIX/RFC3280 certificate validation error was GSKVAL_ERROR_NO_CHAIN_BUILT blah blah blah ...
That's what I'd got while trying to setup a reverse proxy using IBM HTTP Server (IHS) to a target web server which installed GeoTrust SSL cert, had taken me a nice Friday evening :(. Basic Apache version of the HTTP server works fine. If any of you run into this problem, the following quick tips would make your day a beautiful one.
- Handshake failed, so it should be problem with setting up of your cert
- Basic Apache version works just fine, so it must be something related to mod_ibm_ssl which IHS uses with more stringent validation (Apache uses mod_ssl)
I came out with a quick trying to simply add the target machine's root CA cert to my IHS cert store (the .kdb file).
- Download the root CA cert of the cert being used by the target machine. In my case, it was GeoTrust (and I was struggling to figure out what should I use in the long list provided by GeoTrust which was confusing: http://www.geotrust.com/resources/root-certificates/ . It turns out that the Root 2 is the right one to go with: http://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem)
- Use the ikeyman tool to open the .kdb file being used by your IHS and import (retrieve) the root CA you just downloaded.
- Restart your IHS and you're all set.
Hope this helps.
Friday, June 14, 2013
iOS 7 và xu thế di động hoá cho doanh nghiệp
Trong hội thảo thường niên dành cho nhà phát triển gần đây (Apple WWDC), Apple đã giới thiệu về phiên bản mới của hệ điều hành dành cho iPhone/iPad của hãng (iOS7). Bên cạnh những tính năng mới tập trung vào người dùng cá nhân (consumers) như thường lệ, có vẻ như Apple đang nắm bắt được những gì mà xu thế di động hoá doanh nghiệp (mobile enterprise) đang cần từ những thiết bị của mình để đưa chúng vào từng ngõ ngách của đời sống di động. Dưới đây là một vài tính năng đáng lưu ý nhìn từ góc độ mobile enterprise.
1. Mạng riêng ảo cho từng ứng dụng (Per app VPN)
Đây thực sự là một điểm nhấn trong iOS 7 đứng trên phương diện bảo mật để các CIOs có thêm lý do chấp nhận đưa thiết bị di động của Apple vào các hoạt động của doanh nghiệp. Một trong những thách thức trong quá trình di động hoá doanh nghiệp là làm sao cho phép thiết bị di động kết nối vào mạng riêng của công ty, tổ chức một cách an toàn, bảo mật. Kết nối VPN có ưu điểm là tiện lợi, hiệu năng (performance) cao nhưng lại có một trở ngại lớn là phải có khả năng kiểm soát được toàn bộ thiết bị, vì một khi được thiết lập, các ứng dụng khác trên đó đều có khả năng xử dụng kết nối VPN để truy cập đến mạng trong của doanh nghiệp. Điều này mang lại rất nhiều rủi ro. Cách tiếp cận cho phép “nhúng” khả năng kết nối VPN vào từng ứng dụng cụ thể giải quyết tốt vấn đề này. Nó cho phép doanh nghiệp quản lý được việc truy cập đến tài nguyên mạng nội bộ của mình dễ dàng hơn, bằng việc giới hạn khả năng đó ở những ứng dụng được doanh nghiệp phát triển hoặc kiểm duyệt chặt chẽ. Trên thực tế đã có giải pháp theo hướng này như openVPN, nhưng một khi per app VPN có sẵn trong core của hệ điều hành, việc phát triển ứng dụng hướng tới doanh nghiệp thực sự sẽ trở nên dễ dàng và tiết kiệm hơn rất nhiều.
Dữ liệu nhiều khi được coi là quý hơn rất nhiều so với thiết bị đang lưu nó. Việc mã hoá dữ liệu trên toàn bộ thiết bị đôi khi là bắt buộc đối với nhiều tổ chức, doanh nghiệp. iPhone/iPad/iPod chưa hề cung cấp khả năng đó, nên hầu hết việc bảo mật dữ liệu phó mặc cho người phát triển ứng dụng, chỉ với việc cung cấp những giao diện lập trình (API) cho phép mã hoá dữ liệu. Thực tế không phải người phát triển nào cũng tuân thủ đầy đủ những yêu cầu tỉ mỉ đó, đòi hỏi tốn nhiều công sức hơn trong việc duyệt, kiểm tra, có thể, từ mức mã nguồn. Nếu việc mã hoá dữ liệu là bắt buộc ngay từ mức phát triển ứng dụng, Apple có thể đã thêm 1 điểm cộng cho việc thiệt bị của mình được lựa chọn dùng trong việc di động hoá của doanh nghiệp.
SSO là nhu cầu phổ biến trong các ứng dụng IT của doanh nghiệp, đặc biệt là những ứng dụng trên web. Nhưng câu chuyện trở nên phức tạp hơn nhiều khi thực hiện SSO trên ứng dụng cho thiết bị di động. Với thiết bị iOS, việc này càng trở nên phức tạp hơn bởi việc chia sẻ thông tin giữa các ứng dụng (cần thiết cho thực hiện SSO) trên iOS là không hề dễ dàng. Nếu Apple cung cấp giao diện phát triển (API) phục vụ cho SSO thì tính năng “1 cửa” dễ chịu này sẽ được thực hiện 1 cách tự nhiên, dễ dàng hơn, đem thiết bị iOS đến gần hơn với doanh nghiệp.
Từ phương diện quản lý thiết bị, Apple nói đến 2 điểm nhấn trong iOS 7: Một là khả năng khoá những dịch vụ trên thiết bị khi cần như thoại (Phone), iMessage, FaceTime. Có vẻ đây là một trọng những tính năng mấu chốt trong phiên bản được Bộ quốc phòng Mỹ phê duyệt cho nhân viên dùng thiết bị iOS cho việc truy cập những thông tin mật. Hai là khả năng dễ dàng tích hợp thiết bị iOS với hệ thống quản lý thiết bị sẵn có của một doanh nghiệp, bằng những cải tiến trong giao diện phát triển với MDM (MDM API).
iCloud keychain sẽ lưu trữ tất cả thông tin về mật khẩu của người dùng lên đám mây iCloud với khả năng đồng bộ những thông tin bảo mật đó giữa các thiết bị Apple khác nhau của người dùng. Thông tin được mã hoá chuẩn AES 256-bit và chỉ được đồng bộ qua những thiết bị đã được chứng thực từ người dùng (trusted devices) sẽ giúp cho người dùng khỏi đắn đo khi quyết định dùng iCloud keychain.
Trong quá trình di động hoá diễn ra ngày càng rõ nét ở các doanh nghiệp, tổ chức, một xu thế phổ biến là BYOD (Bring Your Own Device) có lẽ đang trở thành tất yếu, nói đến việc nhân viên có thể dùng thiết bị cá nhân của mình cho công việc hàng ngày. Apple là một trong những nhà cung cấp thiết bị di động chính cho thị trường, và từ trước tới nay hãng chủ yếu chú trọng đến khách hàng cá nhân. Nhưng những điểm mới trong lần giới thiệu về iOS 7 này cho thấy Apple có lẽ đang chuẩn bị cho những ảnh hưởng mới của mình tới mảng thị trường doanh nghiệp đang bị chế ngự bởi RIM.
Wednesday, June 12, 2013
Bypass firewalls easily with SSH tunneling
In many cases, you want to have access from a device to an isolated network such as your company intranet to which the device does not have direct connection, but your personal computer does.
A common situation is when you're developing applications for mobile devices that needs the connection between the devices and some back-end servers placed inside an intranet where, for some reasons, only your laptop has ability to connect to though a Virtual Private Network (VPN), eg: When you are working from home.
So how can you still get your mobiles connected to the back-end servers for testing from home? It's easy and can quickly be done by some simple steps:
- Make sure your mobile can connect to your laptop, eg: Through a WIFI network which you most likely already had at home.
- Setup an ssh tunnel from your laptop to the back-end servers to drive any traffic from your mobile devices to the servers through your laptop.
For the second step, on a Mac, you can simply open up your terminal and type something like this:
$ ssh -Lyour.local.ipaddress:port1:your.backend.serveraddress:port2 yoursshaccount@serveraddress.where.you.wanttoconnect
(You better use a port greater than or equal to 1024 because lower ones are reserved ports and you need some special dealing to open them up)
For example:
$ ssh -L192.168.2.100:7777:work.mycompany.com:22 duynv@gate.mycompany.com
This means open an ssh connection as user duynv to host gate.mycompany.com. While the session is openned, redirect all traffic to port 7777 on the local machine (192.168.2.100) to port 22 on machine work.mycompany.com
You can add more servers, ports to the list as needed and then you're all set.
Now you can use your mobile devices, connect to your laptop, on a specific port and enjoy trying apps on your mobile without having to deal with tons of complexity getting your devices connected to the intranet, and more importantly you can make your works done remotely from home.
A common situation is when you're developing applications for mobile devices that needs the connection between the devices and some back-end servers placed inside an intranet where, for some reasons, only your laptop has ability to connect to though a Virtual Private Network (VPN), eg: When you are working from home.
So how can you still get your mobiles connected to the back-end servers for testing from home? It's easy and can quickly be done by some simple steps:
- Make sure your mobile can connect to your laptop, eg: Through a WIFI network which you most likely already had at home.
- Setup an ssh tunnel from your laptop to the back-end servers to drive any traffic from your mobile devices to the servers through your laptop.
For the second step, on a Mac, you can simply open up your terminal and type something like this:
$ ssh -Lyour.local.ipaddress:port1:your.backend.serveraddress:port2 yoursshaccount@serveraddress.where.you.wanttoconnect
(You better use a port greater than or equal to 1024 because lower ones are reserved ports and you need some special dealing to open them up)
For example:
$ ssh -L192.168.2.100:7777:work.mycompany.com:22 duynv@gate.mycompany.com
This means open an ssh connection as user duynv to host gate.mycompany.com. While the session is openned, redirect all traffic to port 7777 on the local machine (192.168.2.100) to port 22 on machine work.mycompany.com
You can add more servers, ports to the list as needed and then you're all set.
Now you can use your mobile devices, connect to your laptop, on a specific port and enjoy trying apps on your mobile without having to deal with tons of complexity getting your devices connected to the intranet, and more importantly you can make your works done remotely from home.
Tuesday, June 11, 2013
Would WebSockets security vulnerabilities be a showstopper?
When
you're developing interactive applications with simultaneous editing
ability (for example, a virtual collaborative whiteboard, chat,
online game or real-time reporting system over the web), using the
traditional loosely coupled HTTP request/response web model is
obviously not an efficient way to go. That approach is simply not
designed for a real-time model. We need a more lightweight protocol
that can provide a full-duplex communication channel between
endpoints of the system to achieve as near a real-time experience as
possible.
This
need is becoming critical as such applications are deployed and run
in the mobile world, where the resources for staying connected are
sometimes very limited: limited bandwidth, limited memory, lots of
potential latency.
A
number of creative approaches—work-arounds—aiming to create a
real-time feeling for users have been implemented (for example, Ajax,
Comet). So far these have served the connected world well by bringing
together good user experience with the ability to shorten the time in
which data is being sent between client and server. But these
approaches still have several limitations from a resource-consumption
perspective: a huge redundancy of network traffic, server demands and
the complication of maintaining two HTTP connections between
endpoints (one for the upstream and another for the downstream).
Using
WebSockets is a big step forward in the effort to create an engaging,
interactive user experience. It could provide capabilities such as
real bidirectional communication, low latency, significant reduction
of overhead and dramatically reduced complexity of implementation.
From a security
standpoint, though, some people are afraid of using WebSockets due to
some risks that would create vulnerabilities. WebSockets’
application
programming interface (API) allows establishing WebSockets
connections across domains without the user’s acknowledgement, and
requests are sent without noticing the
user. This makes it possible for the attacker to inject malicious
JavaScript code into the victim’s client application (the user
agent; for example, browser, mobile app and so forth) to establish a
WebSockets connection to an arbitrary target. The connection can then
be utilized by the attacker for malicious purposes, such as:
- Remote shell, web-based botnet, port scanning
Cross-site
scripting (XSS) vulnerability has been common in web technology, but
utilizing WebSockets introduces some threats that would give an
attacker more power to control the victims—assuming that the user
somehow visits a malicious service, or a website that has XSS
vulnerability exploited, from the user agent. Once loaded in the user
agent, malicious JavaScript code can be executed and the attacker can
easily establish a WebSockets connection to a malicious server and
create a remote shell to utilize the victims for malicious purposes:
a Distributed Denial of Service (DDoS) attack (with lots of victims),
access to the company’s intranet services for information, port
scanning or using the victim’s user agent as a proxy, a springboard
for other attacks.
- Friendship between WebSockets and proxies, firewalls
In
November 2010, a serious security issue involving WebSockets was
reported. WebSockets was still not adopted widely enough, so some
transparent proxies didn’t correctly understand the HTTP upgrade
mechanism being used for the handshaking of WebSockets and thus can
potentially allow a cache poisoning attack. Frame-masking was added
to avoid that vulnerability, but in turn the frame-masking and other
natural lightweight features of the protocol (lack of metadata like
HTTP header, content length) challenge the virus and malware scanning
tools in analyzing the data patterns to detect malicious content in a
malicious usage of WebSockets channel.
The
vulnerabilities are mostly not specific to WebSockets API or the
protocol, but the freedom of the new data exchange model opens up
more threats and needs more attention to secure the communication.
Best practices for traditional web programming should still be
applied for WebSockets.
- Maximize the validation on both client and server side against the received input. Client and server basically should not trust each other by default.
- Maximize the use of Transport Layer Security (TLS) encryption to achieve integrity.
- Carefully implement authentication and session management between endpoints.
When
you are struggling with the trade-off between security and
performance while deciding whether or not to use WebSockets, it might
be a good choice to utilize a well-known solution for your particular
need. One of the proposals to deploy your application that uses
WebSockets is to not make it a mobile web application that runs on
web browsers of the users’ mobile devices, but instead to use an
alternative way—to build a hybrid mobile application and stick your
client application with a proven server-side solution, for example,
Node.JS (and Socket.IO, or Worlize).
IBM
Worklight offers you a way to easily build a hybrid mobile
application (and much more). You can basically build your app in a
web-based code such as JavaScript, CSS or HTML just like a web
application, but the code will eventually run on top of a thin native
container that utilizes the device’s webkit engine, instead of
using the mobile browser itself (you need some work-around for
dealing with Android though, because unfortunately WebSockets has not
been supported in its embedded webkit engine yet).
Be
well aware of the security vulnerabilities of using WebSockets.
Dealing with them properly will help you to build a secure,
interactive mobile application and enjoy the near real-time
experience on your mobile devices in a collaborative world where time
is precious and conserving resources is critical.
More details: Mobile Frontier IBM, Mobile Business Insights IBM
Thursday, June 06, 2013
Migrating Node.js under root to run under a non-root user
On Linux, if you want to
open a port less than 1025, you normally need run as root. Running a
web application (runs on port 80/443, in the above range) entirely
under root user is really dangerous and is obviously not recommended.
Most of web servers only run a master process as root and delegates works to other helper processes which run with lower privileges to perform. But Node.js runs with single-process model, then if you plan to run Node.js in Linux systems it's a little bit tricky to deal with the port issue.
Fortunately, on modern releases of Linux, you can use capabilities setting to work out of that. You only need the root access to install and setup the capabilities setting to tell the system to allow Node.js binding services on low ports ( port # < 1025)
Commands to do that are very straight forward and simple:
Install the capabilities tool:
$ sudo apt-get install libcap2-bin
Grant Node.js to bind services on low ports:
$ sudo setcap cap_net_bind_service=+ep <Path to Node.js> Eg: /usr/nodejs/bin/node
And now you can run node.js without having to sudo to root
But what if you already installed and run your application under root, and you want to switch everything over to a lower privileged user? That's also quite easy with following steps:
That's it.
Most of web servers only run a master process as root and delegates works to other helper processes which run with lower privileges to perform. But Node.js runs with single-process model, then if you plan to run Node.js in Linux systems it's a little bit tricky to deal with the port issue.
Fortunately, on modern releases of Linux, you can use capabilities setting to work out of that. You only need the root access to install and setup the capabilities setting to tell the system to allow Node.js binding services on low ports ( port # < 1025)
Commands to do that are very straight forward and simple:
Install the capabilities tool:
$ sudo apt-get install libcap2-bin
Grant Node.js to bind services on low ports:
$ sudo setcap cap_net_bind_service=+ep <Path to Node.js> Eg: /usr/nodejs/bin/node
And now you can run node.js without having to sudo to root
But what if you already installed and run your application under root, and you want to switch everything over to a lower privileged user? That's also quite easy with following steps:
- Create a new user
$ useradd node_app -G nodegroup
- Copy your web
application directories to another place
$ cp -R /path/to/the/app /new/destination/
- Change owner of the
directories to the node_app:nodegroup under which you want your app
runs
$chown -R node_app:nodegroup /new/destination/
- Change the owner of
node.js run time directories to the new user:group
$chown -R node_app /user/nodejs
- Run the
capabilities setting commands above
That's it.
Subscribe to:
Posts (Atom)