Wired device not managed , unmanaged in debian

debian-logo

wired device not managed

Most probably your interface appears in /etc/network/interfaces. By default, NetworkManager does not manage interfaces that appear in /etc/network/interfaces. You can change this behaviour.

To do this – in a terminal:

sudo nano /etc/NetworkManager/NetworkManager.conf

change the line managed=false to managed=true

Save, stop and start network manager:

sudo service network-manager restart

No WiFi on Dell Inspiron 5559 with Debian Jessie and Kernel 4.2

How to resolve WiFi issues on Dell Inspiron 5559 running Debian Jessie with kernel 4.2.

How to Resolve on Debian Jessie

For custom +4.2 kernels, check this link and download the appropriate wireless driver:

# wget https://wireless.wiki.kernel.org/_media/en/users/drivers/iwlwifi-3160-ucode-15.227938.0.tgz
# tar xf iwlwifi-3160-ucode-15.227938.0.tgz
# cd iwlwifi-3160-ucode-15.227938.0
# cp iwlwifi-3160-15.ucode /lib/firmware/

Reload the module:

# modprobe -r iwlwifi ; modprobe iwlwifi

WiFi should be working now.

The lspci snippet:

01:00.0 Network controller: Intel Corporation Wireless 3160 (rev 83)
	Subsystem: Intel Corporation Dual Band Wireless AC 3160
	Flags: bus master, fast devsel, latency 0, IRQ 125
	Memory at d1100000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [40] Express Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Device Serial Number 78-0c-b8-ff-ff-4b-66-8a
	Capabilities: [14c] Latency Tolerance Reporting
	Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1 Len=014 <?>
	Kernel driver in use: iwlwifi

VirtualBox Guest Additions upgrade in vvv osx

vagrant

vagrant-vbguest

vagrant-vbguest is a Vagrant plugin which automatically installs the host’s VirtualBox Guest Additions on the guest system.

Installation

Requires vagrant 0.9.4 or later (including 1.x)

Vagrant ≥ 1.1

$ vagrant plugin install vagrant-vbguest

from https://github.com/dotless-de/vagrant-vbguest

OwnCloud is in maintenance mode after upgrade

owncloud

I went into my config.php file and put maintenance mode from true to false.

Rebooted apache, refreshed the page and it went through the upgrade procedure again, and boom, good to go 🙂

 

from OwnCloud forum https://forum.owncloud.org/viewtopic.php?f=23&t=9024

wp_termmeta doesn’t exist error [SOLVED]

CREATE TABLE `wp_termmeta` (
  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `term_id` bigint(20) unsigned NOT NULL DEFAULT '0',
  `meta_key` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `meta_value` longtext COLLATE utf8mb4_unicode_ci,
  PRIMARY KEY (`meta_id`),
  KEY `term_id` (`term_id`),
  KEY `meta_key` (`meta_key`(191))
) ENGINE=InnoDB AUTO_INCREMENT=3255 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Use this SQL query to add manually the wp_termmeta table in your WordPress Database if there is the error wp_termmeta doesn’t exist

Jetpack: Protection From Brute Force XML-RPC Attacks

jetpack
Posted on October 12, 2015 by Carolyn Sonnek

You may have read the recent news report from Sucuri about the latest vulnerability to your WordPress XML-RPC file: Brute Force Amplification Attacks via WordPress XML-RPC

Brute force attacks against XML-RPC are one of the oldest and most common types of attacks to your site. Recently, according to Sucuri’s post above, attackers have found a way to “amplify” these attacks – making it easier for attackers to try and break into your site.

How can you protect yourself from these attacks?

Simple. Use Jetpack’s Protect module.

Sam Hotchkiss, one of our Jetpack developers, wrote an article today on his blog going over the more technical details on how this new attack method works and how Jetpack protects you from this new threat.

If you’re running Jetpack with Protect enabled, you don’t need to do anything to keep yourself safe from this. We’ve already got it taken care of for you!

from https://jetpack.me/2015/10/12/jetpack-protection-from-brute-force-xml-rpc-attacks/

Hard Coded Links in Theme File Causing Error

wordpress-logo_s

The Theme Check plugin checks for errors in your design or coding of WordPress themes.

If you are getting “INFO: Possible hard-coded links were found”, that literally means you have hard-coded links, you typed the URL in. Proper links should have been “escaped”, or passed through a function to make sure they contain only characters that are valid in URLs. If the URL is used in multiple places, you also should consider putting the URL in a PHP variable so if you need to change it, you change it in only one place.

http://codex.wordpress.org/Theme_Development
“Untrusted Data
“You should escape dynamically generated content in your Theme, especially content that is output to HTML attributes. As noted in WordPress Coding Standards, text that goes into attributes should be run through esc_attr() so that single or double quotes do not end the attribute value and invalidate the XHTML and cause a security issue. Common places to check are title, alt, and value attributes.”

http://codex.wordpress.org/Function_Reference/esc_url
Here is an example from the twentyfourten theme footer:

<div class="site-info">
<?php do_action( 'twentyfourteen_credits' ); ?>
<a href="<?php echo esc_url( __( 'http://wordpress.org/', 'twentyfourteen' ) ); ?>"><?php printf( __( 'Proudly powered by %s', 'twentyfourteen' ), 'WordPress' ); ?></a>
</div><!-- .site-info -->

Original:

<a href="http://mydomain.com" target="_blank">my domain</a>

Try this instead of your original:

<a href="<?php echo esc_url( __('http://mydomain.com', 'mytheme'));?>" target="_blank">my domain</a>

That is underscore underscore parenthesis (for translating your theme to other languages), see http://codex.wordpress.org/Function_Reference/_2

From
http://lcblog.lernerconsult.com/2014-hard-coded-links-in-theme-file-causing-error

Fail2ban WordPress Nginx

wordpress_fail2ban

I’ve been using the Limit Login Attempts plugin for WordPress for quite a while. It basically logs failed login attempts and automatically blocks multiple attempts from a single IP address. A few days ago I’ve switched to fail2ban instead, which is pretty new to me.

Fail2ban is a fairly simple yet very flexible framework that monitors log files for certain patterns, and runs preconfigured actions upon certain events.

Out of the box fail2ban comes with many so called filters, which are sets of matching rules, for example SSH auth failure, vsftpd login failure and more. As well as predefined actions, like block the IP address via iptables, send an e-mail with the IP WHOIS info, etc.

I haven’t had too much time to play around with the configs, but I did manage to get it to work with my WordPress install on nginx, and here’s how.

I created a new security.php plugin in wp-content/mu-plugins with the following code (not really sure why Core doesn’t do this already):

<?php
function my_login_failed_403() {
    status_header( 403 );
}
add_action( 'wp_login_failed', 'my_login_failed_403' );

Basically the problem is that WordPress returns authentication failure with the status code of 200, which is the same status code of an authentication success, so there’s no easy way to tell the difference between the two just by looking at nginx’s access log.

The above code adds the 403 status code to failed login attempts, either via wp-login.php or xmlrpc.php.

Next, assuming you’ve already installed fail2ban (sudo apt-get install fail2ban) let’s define a new filter in /etc/fail2ban/filter.d and call it wordpress-auth.conf:

[Definition]
failregex = <HOST>.*POST.*(wp-login\.php|xmlrpc\.php).* 403 

If you look at other files in filter.d, you’ll know what’s going on. failregex is a regular expression that matches a POST request to wp-login.php or xmlrpc.php with a status code of 403 in nginx’s access logs, assuming you’re using the default format. Probably not the best and fastest regex in the world, but serves its purpose.

Finally, let’s create a jail for all those bruteforce script kiddies. Let’s append the following code to the end of /etc/fail2ban/jail.conf:

[wordpress]

enabled  = true
port     = http,https
filter   = wordpress-auth
logpath  = /var/log/nginx/access.log
maxretry = 3
bantime  = 3600

This is pretty easy to understand. We’re going to use our new wordpress-auth filter against nginx’s access.log file (double check the path) and ban IPs for one hour upon three or more failed attempts. Then we’re gonna restart the fail2ban daemon and watch the logs:

$ sudo service fail2ban restart
$ sudo tail -f /var/log/fail2ban.log
2014-01-16 05:46:54,372 fail2ban.actions: WARNING [wordpress] Ban 78.189.190.31
2014-01-16 06:05:01,915 fail2ban.actions: WARNING [wordpress] Ban 78.191.242.241
2014-01-16 06:37:50,345 fail2ban.actions: WARNING [wordpress] Ban 78.166.122.173
...

Nice!

It is also a good idea to enable fail2ban for monitoring SSH access, FTP and any other services you’re running on your server. Up until a few days ago, I haven’t even realized someone was trying to bruteforce my SSH password. Now I get e-mail alerts everyday.

Frome the Great

Fail2ban WordPress Nginx