#StackBounty: #apache #denial-of-service How to prove the Apache web server is not accepting connections anymore because of an denial o…

Bounty: 50

I have a network dump (PCAP file) from a “conversation” between a web server apache ( and some clients:


What a should look for to prove that the server buffer (or TCP WINDOW) is full? I received 403 error (error.log). I know it was a denial of service attack (slowloris).

Get this bounty!!!

Installing Apache UserGrid on linux

About the Project

Apache Usergrid is an open-source Backend-as-a-Service (BaaS or mBaaS) composed of an integrated distributed NoSQL database, application layer and client tier with SDKs for developers looking to rapidly build web and/or mobile applications. It provides elementary services and retrieval features like:

  • User Registration & Management
  • Data Storage
  • File Storage
  • Queues
  • Full Text Search
  • Geolocation Search
  • Joins

It is a multi-tenant system designed for deployment to public cloud environments (such as Amazon Web Services, Rackspace, etc.) or to run on traditional server infrastructures so that anyone can run their own private BaaS deployment.

For architects and back-end teams, it aims to provide a distributed, easily extendable, operationally predictable and highly scalable solution. For front-end developers, it aims to simplify the development process by enabling them to rapidly build and operate mobile and web applications without requiring backend expertise.

Usergrid 2.1.0 Deployment Guide

Though the Usergrid Deployment guide seems to be simple enough, I faced certain hiccups and it took me about 4 days to figure out what I was doing wrong.

This document explains how to deploy the Usergrid v2.1.0 Backend-as-a-Service (BaaS), which comprises the Usergrid Stack, a Java web application, and the Usergrid Portal, which is an HTML5/JavaScript application.


Below are the software requirements for Usergrid 2.1.0 Stack and Portal. You can install them all on one computer for development purposes, and for deployment you can deploy them separately using clustering.

Linux or a UNIX-like system (Usergrid may run on Windows, but we haven’t tried it)

Download the Apache Usergrid 2.1.0 binary release from the official Usergrid releases page:

After untarring the files that you need for deploying Usergrid Stack and Portal are ROOT.war and usergrid-portal.tar.

Stack STEP #1: Setup Cassandra

As mentioned in prerequisites, follow the installation guide given in link

Usergrid uses Cassandra’s Thrift protocol
Before starting cassandra, on Cassandra 2.x releases you MUST enable Thrift by setting start_rpc in your cassandra.yaml file:

    #Whether to start the thrift rpc server.
    start_rpc: true

Note:DataStax no longer supports the DataStax Community version of Apache Cassandra or the DataStax Distribution of Apache Cassandra. It is best to follow the Apache Documentation

Once you are up and running make a note of these things:

  • The name of the Cassandra cluster
  • Hostname or IP address of each Cassandra node
    • in case of same machine as Usergrid, then localhost. Usergrid would then be running on single machine embedded mode.
  • Port number used for Cassandra RPC (the default is 9160)
  • Replication factor of Cassandra cluster

Stack STEP #2: Setup ElasticSearch

Usergrid also needs access to at least one ElasticSearch node. As with Cassandra, you can setup single ElasticSearch node on your computer, and you should run a cluster in production.


  • Download and unzip Elasticsearch
  • Run bin/elasticsearch (or bin\elasticsearch -d on Linux as Background Process) (or bin\elasticsearch.bat on Windows)
  • Run curl http://localhost:9200/

Once you are up and running make a note of these things:

  • The name of the ElasticSearch cluster
  • Hostname or IP address of each ElasticSearch node
    • in case of same machine as Usergrid, then localhost. Usergrid would then be running on single machine embedded mode.
  • Port number used for ElasticSearch protocol (the default is 9200)

Stack STEP #3: Setup Tomcat

The Usergrid Stack is contained in a file named ROOT.war, a standard Java EE WAR ready for deployment to Tomcat. On each machine that will run the Usergrid Stack you must install the Java SE 8 JDK and Tomcat 7+.

Stack STEP #4: Configure Usergrid Stack

You must create a Usergrid properties file called usergrid-deployment.properties. The properties in this file tell Usergrid how to communicate with Cassandra and ElasticSearch, and how to form URLs using the hostname you wish to use for Usegrid. There are many properties that you can set to configure Usergrid.

Once you have created your Usergrid properties file, place it in the Tomcat lib directory. On a Linux system, that directory is probably located at /path/to/tomcat7/lib/

The Default Usergrid Properties File

You should review the defaults in the above file. To get you started, let’s look at a minimal example properties file that you can edit and use as your own.

Please note that if you are installing Usergrid on the same machine as Cassandra Server, then set the following property to true

   #Tell Usergrid that Cassandra is not embedded.

Stack STEP #5: Deploy ROOT.war to Tomcat

The next step is to deploy the Usergrid Stack software to Tomcat. There are a variety of ways of doing this and the simplest is probably to place the Usergrid Stack ROOT.war file into the Tomcat webapps directory, then restart Tomcat.

Look for messages like this, which indicate that the ROOT.war file was deployed:

INFO: Starting service Catalina
Jan 29, 2016 1:00:32 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.59
Jan 29, 2016 1:00:32 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive /usr/share/tomcat7/webapps/ROOT.war

Does it work?

you can use curl:

curl http://localhost:8080/status

If you get a JSON file of status data, then you’re ready to move to the next step. You should see a response that begins like this:

“timestamp” : 1454090178953,
“duration” : 10,
“status” : {
“started” : 1453957327516,
“uptime” : 132851437,
“version” : “201601240200-595955dff9ee4a706de9d97b86c5f0636fe24b43”,
“cassandraAvailable” : true,
“cassandraStatus” : “GREEN”,
“managementAppIndexStatus” : “GREEN”,
“queueDepth” : 0,
“org.apache.usergrid.count.AbstractBatcher” : {
“add_invocation” : {
“type” : “timer”,
“unit” : “microseconds”,
… etc. …

Initialize the Usergrid Database

Next, you must initialize the Usergrid database, index and query systems.

To do this you must issue a series of HTTP operations using the superuser credentials. You can only do this if Usergrid is configured to allow superused login via this property usergrid.sysadmin.login.allowed=true and if you used the above example properties file, it is allowed.

The three operation you must perform are expressed by the curl commands below and, of course, you will have ot change the password test to match the superuser password that you set in your Usergrid properties file.

curl -X PUT http://localhost:8080/system/database/setup -u superuser:test
curl -X PUT http://localhost:8080/system/database/bootstrap -u superuser:test
curl -X GET http://localhost:8080/system/superuser/setup -u superuser:test

When you issue each of those curl commands, you should see a success message like this:

“action” : “cassandra setup”,
“status” : “ok”,
“timestamp” : 1454100922067,
“duration” : 374

Now that you’ve gotten Usergrid up and running, you’re ready to deploy the Usergrid Portal.

Deploying the Usergrid Portal

The Usergrid Portal is an HTML5/JavaScript application, a bunch of static files that can be deployed to any web server, e.g. Apache HTTPD or Tomcat.

To deploy the Portal to a web server, you will un-tar the usergrid-portal.tar file into directory that serves as the root directory of your web pages.

Once you have done that there is one more step. You need to configure the portal so that it can find the Usergrid stack. You do that by editing the portal/config.js and changing this line:

Usergrid.overrideUrl = ’http://localhost:8080/‘;

To set the hostname that you will be using for your Usergrid installation.

I have deployed a sample instance and tested the same. You can find the system ready configurations in TechUtils repository

#StackBounty: #javascript #node.js #apache #gulp #browser-sync Gulp browser-sync not monitoring and injecting files

Bounty: 50

I have following directory structure


I had installed vhost named as dev.local on ...workspacedev. As you can see I have created a gulpfile.js in my proj directory.

Now if I run gulp browser-sync command my browser window is open showing following url http://dev.local:3000/proj/. It perfectly opens my index.php page but if I do any modification in my files they are not monitored and are not injected into my page. So there is no auto reload of my page.

Here is my gulpfile.js

var gulp = require('gulp');
var bs = require('browser-sync').create(); // create a browser sync instance.

gulp.task('browser-sync', function() {
        open: 'external',
        host: 'dev.local',
        proxy: 'dev.local/proj'

gulp.task('watch', ['browser-sync'], function () {
    gulp.watch("*.html,*.php,css/*.css,js/*.js").on('change', bs.reload);

Here is the output of my terminal

gulp browser-sync
[12:14:12] Using gulpfile ~/Documents/workspace/dev/proj/gulpfile.js
[12:14:12] Starting 'browser-sync'...
[12:14:12] Finished 'browser-sync' after 15 ms
[BS] Proxying: http://dev.local
[BS] Access URLs:
       Local: http://localhost:3000/proj
    External: http://dev.local:3000/proj
          UI: http://localhost:3001
 UI External: http://dev.local:3001

I had already searched SO for various solutions but of no avail. Please help I am stuck.


I am using BrowserSync version 2.18.8 and gulp version 3.9.1

Get this bounty!!!

#StackBounty: Unable to modify(update) posts – Page not found

Bounty: 100

For couple of days I am experiencing issues with modifying some of my posts.
When I try to modify the content of post, I get 404 error, redirecting me that page is not found.

Doing Google research, with all basic tests, clear cache, browser, enable/disable plugins, changing permalinks, etc, I’ve found this on WP forum, saying that Apache’s ModSecurity is causing issues:



However, this doesn’t work for me, because I don’t option in Cpanel to disable ModSecurity – disabled from hosting company.

I’ve got this response from them:

Mod_sec is an important server level security feature. We are not
going to disable mod_sec.

Certain WordPress posts (such as ones that appear to be SQL injection
attacks) may trigger mod_sec, but it certainly is not all WordPress

Is there any work-around to solve this? I have a SSH access, bit limited, but may helps.

Also, I am not 100% sure about – but I’ve noticed that I can(haven’t test all) update my old posts.

Posts that are ~ 5-6m old are throwing 404 error.
WP version is 4.7.2


The only option I have now, is to do a backup of production site, load on my locahost, update posts and push it back to production.

However, this isn’t convenient at all. 🙁
Does anyone have a solution?

Please help!

Get this bounty!!!

Apache Ignite: What is Ignite?

Apache Ignite(TM) In-Memory Data Fabric is a high-performance, integrated and distributed in-memory platform for computing and transacting on large-scale data sets in real-time, orders of magnitude faster than possible with traditional disk-based or flash-based technologies.



You can view Ignite as a collection of independent, well-integrated, in-memory components geared to improve performance and scalability of your application. Some of these components include:

Apache Ignite APIs

Apache Ignite has a reach set of APIs that are covered throughout the documentation. The APIs are implemented in a form of native libraries for such major languages and technologies as Java, .NET and C++ and by supporting a variety of protocols like REST, Memcached or Redis.

The documentation that is located under this domain is mostly related to Java. Refer to the following documentation sections and domains to learn more about alternative technologies and protocols you can use to connect to and work with an Apache Ignite cluster:

Fork It on GIT

Apache Commons DbUtils Mini Wrapper

This is a very small DB Connector code in Java as a wrapper class to Apache DBUtils.

The Commons DbUtils library is a small set of classes designed to make working with JDBC easier. JDBC resource cleanup code is mundane, error prone work so these classes abstract out all of the cleanup tasks from your code leaving you with what you really wanted to do with JDBC in the first place: query and update data.

Some of the advantages of using DbUtils are:

  • No possibility for resource leaks. Correct JDBC coding isn’t difficult but it is time-consuming and tedious. This often leads to connection leaks that may be difficult to track down.
  • Cleaner, clearer persistence code. The amount of code needed to persist data in a database is drastically reduced. The remaining code clearly expresses your intention without being cluttered with resource cleanup.
  • Automatically populate Java Bean properties from Result Sets. You don’t need to manually copy column values into bean instances by calling setter methods. Each row of the Result Set can be represented by one fully populated bean instance.

DbUtils is designed to be:

  • Small – you should be able to understand the whole package in a short amount of time.
  • Transparent – DbUtils doesn’t do any magic behind the scenes. You give it a query, it executes it and cleans up for you.
  • Fast – You don’t need to create a million temporary objects to work with DbUtils.

DbUtils is not:

  • An Object/Relational bridge – there are plenty of good O/R tools already. DbUtils is for developers looking to use JDBC without all the mundane pieces.
  • A Data Access Object (DAO) framework – DbUtils can be used to build a DAO framework though.
  • An object oriented abstraction of general database objects like a Table, Column, or Primary Key.
  • A heavyweight framework of any kind – the goal here is to be a straightforward and easy to use JDBC helper library.


Apache Solr vs Elasticsearch: The Feature Smackdown


Feature Solr 5.3.0 ElasticSearch 2.0
Binary API SolrJ TransportClient, Thrift (through a plugin)
JMX support ES specific stats are exposed through the REST API
Official client libraries Java Java, Groovy, PHP, Ruby, Perl, Python, .NET, JavascriptOfficial list of clients
Community client libraries PHP, Ruby, Perl, Scala, Python, .NET, Javascript, Go, Erlang, Clojure Clojure, Cold Fusion, Erlang, Go, Groovy, Haskell, Java, JavaScript, .NET, OCaml, Perl, PHP, Python, R, Ruby, Scala, Smalltalk, Vert.x Complete list
3rd-party product integration (open-source) Drupal, Magento, Django, ColdFusion, WordPress, OpenCMS, Plone, Typo3, ez Publish, Symfony2, Riak (via Yokozuna) Drupal, Django, Symfony2, WordPress, CouchBase
3rd-party product integration (commercial) DataStax Enterprise Search, Cloudera Search, Hortonworks Data Platform, MapR SearchBlox, Hortonworks Data Platform, MapR etcComplete list
Output JSON, XML, PHP, Python, Ruby, CSV, Velocity, XSLT, native Java JSON, XML/HTML (via plugin)


Feature Solr 5.3.0 ElasticSearch 2.0
Master-slave replication Only in non-SolrCloud. In SolrCloud, behaves identically to ES. Not an issue because shards are replicated across nodes.
Integrated snapshot and restore Filesystem Filesystem, AWS Cloud Plugin for S3 repositories, HDFS Plugin for Hadoop environments, Azure Cloud Plugin for Azure storage repositories


Feature Solr 5.3.0 ElasticSearch 2.0
Data Import DataImportHandler – JDBC, CSV, XML, Tika, URL, Flat File [DEPRECATED in 2.x] Rivers modules – ActiveMQ, Amazon SQS, CouchDB, Dropbox, DynamoDB, FileSystem, Git, GitHub, Hazelcast, JDBC, JMS, Kafka, LDAP, MongoDB, neo4j, OAI, RabbitMQ, Redis, RSS, Sofa, Solr, St9, Subversion, Twitter, Wikipedia
ID field for updates and deduplication
Partial Doc Updates with stored fields with _source field
Custom Analyzers and Tokenizers
Per-field analyzer chain
Per-doc/query analyzer chain
Synonyms Supports Solr and Wordnet synonym format
Multiple indexes
Near-Realtime Search/Indexing
Complex documents
Schemaless 4.4+
Multiple document types per schema One set of fields per schema, one schema per core
Online schema changes Schemaless mode or via dynamic fields. Only backward-compatible changes.
Apache Tika integration
Dynamic fields
Field copying via multi-fields
Hash-based deduplication Murmur plugin or ER plugin


Feature Solr 5.3.0 ElasticSearch 2.0
Lucene Query parsing
Structured Query DSL Need to programmatically create queries if going beyond Lucene query syntax.
Span queries via SOLR-2703
Spatial/geo search
Multi-point spatial search
Faceting Top N term accuracy can be controlled with shard_size
Advanced Faceting New JSON faceting API blog post
Geo-distance Faceting
Pivot Facets
More Like This
Boosting by functions
Boosting using scripting languages
Push Queries JIRA issue Percolation. Distributed percolation supported in 1.0
Field collapsing/Results grouping
Spellcheck Suggest API
Query elevation workaround
Joins Joined index has to be single-shard and replicated across all nodes. via has_children and top_children queries
Resultset Scrolling New to 4.7.0 via scan search type
Filter queries also supports filtering by native scripts
Filter execution order local params and cache property
Alternative QueryParsers DisMax, eDisMax query_string, dis_max, match, multi_match etc
Negative boosting but awkward. Involves positively boosting the inverse set of negatively-boosted documents.
Search across multiple indexes it can search across multiple compatible collections
Result highlighting
Custom Similarity
Searcher warming on index reload Warmers API
Term Vectors API


Feature Solr 5.3.0 ElasticSearch 2.0
Pluggable API endpoints
Pluggable search workflow via SearchComponents
Pluggable update workflow
Pluggable Analyzers/Tokenizers
Pluggable Field Types
Pluggable Function queries
Pluggable scoring scripts
Pluggable hashing
Pluggable webapps site plugin
Automated plugin installation Installable from GitHub, maven, sonatype or elasticsearch.org


Full article

Create Virtual Hosts with Apache

Apache is very flexible, and it’s easy to configure Apache to handle several domains even when your Web server only has one IP address to share between them. You can use this to host multiple sites, or just to provide a sandbox for development rather than making changes on your live site. This weekend, we’ll learn how to create virtual hosts with Apache.

Setting up virtual hosts might seem like a big challenge, but it’s not. In fact, you can set up a virtual host with just a few edits to Apache’s configuration and by setting up additional directories for the documents. For this how to, I want to use an Apache installation on a Ubuntu server. Please be aware, the instructions for this may require modification if being done on a non-Debian distribution because of the way that Apache is packaged. However, the Apache directives should be standard across distributions and should work even if Apache isn’t running on Linux.

Creating the Directory Structure

Before the configurations can be tackled, the directory structure for the virtual site must be created. We are going to be working with Apache as installed on a Ubuntu server, so the Apache document root will be/var/www. The directory structure for the new Web site can be created anywhere. Some create those directories in their home (~/) directory, some create them in /usr/local/apache, and other, various locations. For the sake of simplicity, We are going to illustrate setting the virtual host in the document root of Apache (in Ubuntu that would be /var/www). By doing this, it will not be necessary to change ownership of the newly created directory or the parent directory housing the virtual host (since Apache must have access to the directories and files.)

We are going to set up the virtual host demosite.com. So to create the directories for the virtual host, the following commands must be run:

  • sudo mkdir /var/www/demosite.com
  • sudo chmod -R 755 /var/www/demosite.com

Now that the home directory for the virtual host is done, it’s time to start configuring Apache so it is aware of the new site. After configuring Apache, the site can then be built within /var/www/demosite.com.

Apache Configuration

The first step in the Apache configuration is to make sure Apache knows virtual hosts are enabled. In the Ubuntu set up look for a line (near the bottom) of /etc/apache/apache2.conf that looks like:

Include sites-enabled/

Make sure that line is not commented out (does not begin with a ‘#‘ character). That sites-enabled include points to /etc/apache/sites-enabled. A look in that directory will reveal a file called 000-default. That file should contain all of the directory containers needed for virtual sites on the server. To create a new virtual host (to map the example demosite.com), create a new file within sites-available called /etc/apache/sites-available/demosite.com. The contents of that file will look something similar to this (depending upon the needs and application of the virtual host):

<VirtualHost test.domain.com>
   ServerAdmin webmaster@localhost
   #We want to be able to access the web site using www.test.domain.com or test.domain.com
   ServerAlias www.test.domain.com
   DocumentRoot /var/www/demosite.com
   #log file for this server
   CustomLog /var/log/apache2/www.test.domain.com-access.log combined

The above code assumes that domain.com is the actual domain to be used (insert proper domain where necessary). It’s almost ready to fire up, but we have two simple steps left before restarting Apache. The first step is to create a link in /etc/apache/sites-enabled to the file we just created. This is done with the following steps:

  1. Change to the /etc/apache/sites-enabled directory with the command cd /etc/apache/sites-enabled .
  2. Create the link with the command sudo ln -s /etc/apache/sites-available demosite.com .

It is also possible to create the links automatically with the command sudo a2ensite demosite.com and then, should the virtual site need to be disabled, remove the link with the command sudo a2dissite demosite.com.

The last step is to make sure the server knows that our new virtual site is to be found on the server and not out on the Internet. For this, do the following:

  • Open up the /etc/hosts file in a text editor (with administrative rights).
  • Add a line like localhost.localdomain localhost test.domain.com www.demosite.com .
  • Save and close that file.

Now it’s time to restart Apache with the command sudo /etc/init.d/apache2 restart and test virtual host by pointing a browser to the address.

Non-Debian Servers

If the server hosting the virtual sites is a non-Debian distribution, the steps are different for hosting virtual sites. Here’s how it works:

  1. Create the directory container for the virtual site in /etc/httpd/conf/httpd.conf. This container will look similar to that used for the Debian-based server.
  2. Make sure the Apache configuration file is aware of virtual hosts by making sure the line Include conf.d/*.conf is not commented out.
  3. Create the new virtual hosts file (we’ll call it vhosts.conf) in /etc/httpd/conf.d/ .
  4. Add the virtual site to the /etc/hosts file.
  5. Restart Apache with the command /etc/rc.d/init.d/httpd restart.

The directory container, for the non-Debian host, will look similar to the very basic container below:

<VirtualHost *:80>
   ServerName demosite.com
   DocumentRoot /var/www/html/demosite.com

The virtual hosts file mentioned above, will need to look like this:

   DocumentRoot /var/http/www/demosite.com
   ServerName www.demosite.com

   DocumentRoot /var/http/www/demosite.com
   ServerName test.demosite.com

Building Time

Now that the virtual host is up and running, it is now possible to build the site within the/var/www/demosite.com directory.

You can do this for as many virtual hosts as you need (assuming the server can take the added load).