Fedora Crontab location

/var/spool/cron/

Fix bad sectors in linux ext4 volume

fsck /dev/volume_group_name/volume_name

MySQL database maintenance

To rebuild a table by dumping and reloading it, use mysqldump to create a dump file and mysql to reload the file:

shell> mysqldump db_name t1 > dump.sql
shell> mysql db_name < dump.sql

To rebuild all the tables in a single database, specify the database name without any following table name:

shell> mysqldump db_name > dump.sql
shell> mysql db_name < dump.sql

To rebuild all tables in all databases, use the --all-databases option:

shell> mysqldump --all-databases > dump.sql
shell> mysql < dump.sql

To rebuild a table with ALTER TABLE, use a “null” alteration; that is, an ALTER TABLE statement that “changes” the table to use the storage engine that it already has. For example, if t1 is a MyISAM table, use this statement:

mysql> ALTER TABLE t1 ENGINE = MyISAM;

If you are not sure which storage engine to specify in the ALTER TABLE statement, use SHOW CREATE TABLE to display the table definition.

If you must rebuild a table because a table checking operation indicates that the table is corrupt or needs an upgrade, you can use REPAIR TABLE if that statement supports the table's storage engine. For example, to repair aMyISAM table, use this statement:

mysql> REPAIR TABLE t1;

For storage engines such as InnoDB that REPAIR TABLE does not support, use mysqldump to create a dump file and mysql to reload the file, as described earlier.

For specifics about which storage engines REPAIR TABLE supports, see Section 13.7.2.6, “REPAIR TABLE Syntax”.

mysqlcheck --repair provides command-line access to the REPAIR TABLE statement. This can be a more convenient means of repairing tables because you can use the --databases or --all-databases option to repair all tables in specific databases or all databases, respectively:

shell> mysqlcheck --repair --databases db_name ...
shell> mysqlcheck --repair --all-databases

For incompatibilities introduced in MySQL 5.1.24 by the fix for Bug #27877 that corrected the utf8_general_ciand ucs2_general_ci collations, a workaround is implemented as of MySQL 5.1.62, 5.5.21, and 5.6.5. Upgrade to one of those versions, then convert each affected table using one of the following methods. In each case, the workaround altering affected columns to use the utf8_general_mysql500_ci and ucs2_general_mysql500_cicollations, which preserve the original pre-5.1.24 ordering of utf8_general_ci and ucs2_general_ci.

• To convert an affected table after a binary upgrade that leaves the table files in place, alter the table to use the new collation. Suppose that the table t1 contains one or more problematic utf8 columns. To convert the table at the table level, use a statement like this:

  ALTER TABLE t1
  CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;
  

  To apply the change on a column-specific basis, use a statement like this (be sure to repeat the column definition as originally specified except for the COLLATE clause):

  ALTER TABLE t1
  MODIFY c1 CHAR(N) CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;
  

• To upgrade the table using a dump and reload procedure, dump the table using mysqldump, modify the CREATE TABLE statement in the dump file to use the new collation, and reload the table.

After making the appropriate changes, CHECK TABLE should report no error.

DOS cmd show history

In CMD window, press F7 to view the history of commands in the current cmd session

Cassandra ( C* ) vs RDBMS

To manage c* data, use cassandra-cli or cqlsh

keyspaces@c* = schema@c* = database@RDBMS
columnfamily@c* = table@RDBMS

Cli:

Start cli

> cassandra-cli
cli> connect localhost /9160;

Set active keyspace

cli> use demo;

Update a row in table "users":

cli> set users['user123'][email]='user123@gmail.com';

Select user row

cli> get users['user123']

cql:

> cqlsh

List available keyspaces

cqlsh> describe keyspaces
cql> SELECT * FROM system.schema_keyspaces;

Create keyspace

CREATE KEYSPACE Demo
WITH REPLICATION={ 'class':'SimpleStrategy', 'replication_factor':3 };

Set active keyspace

cql> use Demo;

Show all tables ( columnfamilies )

cqlsh> describe tables | columnfamilies;
cql> select columnfamily_name from system.schema_columnfamilies where keyspace_name=?;

Create table

 CREATE TABLE
        keyspace_name.
        table_name
( column_definition
        , column_definition, ...
        )
        WITH property AND property ...
      

Insert row into a table or columnfamily

INSERT INTO users(id, name, firstname, lastname, email, class)
  VALUES (62c36092-82a1-3a00-93d1-46196ee77204, 'user123',
  'Joe', 'Trader', 'user123@gmail.com', 'admin');

Creating symbolic links in Windows NT file system

using DOS command "mklink"

mklink /d {{link name}} {{target folder}} 

using postgres for ruby development

It is required to install the development components of postgres

Ubuntu:
apt-get install postgresql libpq-dev

Install gem from github

Not verified solution
gem specific_install -l https://github.com/{{username}}/{{gemname}}.git -b {{branchname}}

Ruby: Print first 10 lines from a URI page

require "open-uri"
open("http://www.google.com") { |f| f.each_line{ |line| puts line if f.lineno.between? 1, 10 } }

To print line numbers:
open("http://www.google.com") { |f| f.each_line{ |line| puts "#{f.lineno.to_s.rjust(3,'0')}:#{line}" if f.lineno.between?  1,5 } }

Renew Facebook oauth access token

Expiration and Extending Tokens

Facebook's official SDKs manage the lifetime of tokens for you. When using iOS, Android or our JavaScript SDK, the SDK will handle making sure that tokens are refreshed before they expire.

Native mobile applications using Facebook's SDKs will get long-lived access tokens, good for about 60 days. These tokens will be refreshed once per day when the person using your app makes a request to Facebook's servers. If no requests are made, the token will expire after about 60 days and the person will have to go through the login flow again to get a new token.

Access tokens on the web often have a lifetime of about two hours, but will automatically be refreshed when required. If you want to use access tokens for longer-lived web apps, especially server side, you need to generate a long-lived token. A long-lived token generally lasts about 60 days. This is what the process for generating a long-lived token looks like:

Here are the steps that you need to take to generate a long-lived token:


Start with a short-lived token generated on a client and ship it back to your server.


Use the user token, your app ID and app secret to make the following call from your server to Facebook's servers:


GET /oauth/access_token?  
    grant_type=fb_exchange_token&           
    client_id={app-id}&
    client_secret={app-secret}&
    fb_exchange_token={short-lived-token} 

Make this call from your server, not a client. The app secret is included in this API call, so you should never actually make the request client-side. Instead implement server-side code that makes the request, then pass the response containing the long-lived token back to your client-side code. This will be a different string than the original token, so if you're storing these tokens, replace the old one.

Once you've retrieved the long-lived token, you can use it from your server or ship it back down to the client to use there.


An important note: Apps are unable to exchange an expired short-lived token for a long-lived token. The flow above only works with short-lived tokens that are still valid. Once they expire, your app must send the user through the login flow again to generate a new short-lived token.

Refreshing Long-Lived Tokens

Even the long-lived access token will eventually expire. At any point, you can generate a new long-lived token by sending the person back to the login flow used by your web app - note that the person will not actually need to login again, they have already authorized your app, so they will immediately redirect back to your app from the login flow with a refreshed token - how this appears to the person will vary based on the type of login flow that you are using, for example if you are using the JavaScript SDK, this will take place in the background, if you are using a server-side flow, the browser will quickly redirect to the Login Dialog and then automatically and immediately back to your app again.

After doing the above you will obtain a new short-lived token and then you need to perform the same exchange for a long-lived token as above.

In some cases, this newer long-lived token might be identical to the previous one, but we can't guarantee it and your app shouldn't depend upon it.

With the iOS and Android SDKs, long-lived tokens are used by default and should automatically be refreshed.

Extending Page Access Tokens

Apps can retrieve a page access token from Page admin users when they authenticate with the manage_pages permission. If the user access token used to retrieve this page access token is short-lived, the page access token will also be short-lived.

To get a longer-lived page access token, exchange the User access token for a long-lived one, as above, and then request the Page token. The resulting page access token will not have any expiry time.

Using Long-Lived Tokens on Web Clients

You should, in general, not use the same long-lived tokens on more than one web client (i.e. if the person logs in from more than one computer.) Instead you should use the long-lived tokens on your server to generate a code and then use that to get a long-lived token on the client. Please see below for information Generating long-lived tokens from server-side long-lived tokens.

Generating Long-Lived User Tokens from Server-Side Long-Lived Tokens

Facebook has an advanced option for obtaining long-lived access tokens for apps that:

Have their own authentication system (using a username/password for example)
Store, on their servers, a Facebook access token for people using it that they send to different clients (browser or native mobile apps)
Make API calls from all of those clients


If your app is set up like this it should use the process described here to obtain an access token from each client to avoid triggering Facebook's automated spam systems. The end result will be that each client will have its own long-lived access token.

At a high level, this is how you can obtain a long-lived token from the client:

Make a call to Facebook's server from your server using a valid and current long-lived token to generate a code. (This assumes you've already obtained a long-lived token via Facebook Login. If the token you're using is invalid or expired, you'll have to obtain a new one by making the person using your app log in again.)
Securely send that code to the client.
The client then exchanges the code for a long-lived token.
The client can use the long-lived token to post stories or query data.


This is a diagram of the flow:

Getting the code

Using a long-lived user access token, make a call to the following endpoint:
https://graph.facebook.com/oauth/client_code?access_token=...&client_secret=...&redirect_uri= ...

The call requires the following arguments:


Argument
Required
Description

access_token
Yes
Long-lived user access token.
client_secret
Yes
The app's app secret.
redirect_uri
Yes
The redirect URI must be set to the exact value in the app's configuration.



The response will look something like:
{"code": "...."}

Redeeming the code for an access token

Once you've retrieved the code from Facebook's server you then need to ship it to the client via a secure channel. Once that's done, you need to make a request from the client to this endpoint:
https://graph.facebook.com/oauth/authorize?code=...&client_id=...&redirect_uri=...&machine_id= ...

The call requires the following arguments:


Argument
Required
Description

client_id
Yes
The App ID.
code
Yes
The code returned from Facebook's server.
redirect_uri
Yes
The redirect URI must be set to the exact value in the app's configuration.
machine_id
No
An important per-client (not per-user) value that tracks clients and is used for security. If you're previously made calls to get a code and been provided a machine_id you should include it here.



The response will look like:
{"access_token":"...", "expires_in":..., "machine_id":"..."}

Returned values are:


Value
Description

access_token
A new long-lived access token that you can use for Graph API calls.
expires_in
The number of seconds until this access token expires.
machine_id
The machine_id for this client. Please store this for future calls to generate a new access token from a code. This helps identify this client and is used to prevent spam.