ltoinel

<?php

# Fake Java HTTP server headers
header("Server: WildFly/8",true);
header("X-Powered-By: Undertow/1",true);

/**
 * A Simple Attack logger
 */
function log_attack($log_msg)

suru-dissanaike

#!/bin/bash

IP="192.168.1.22"
SUBJECT_CA="/C=SE/ST=Stockholm/L=Stockholm/O=himinds/OU=CA/CN=$IP"
SUBJECT_SERVER="/C=SE/ST=Stockholm/L=Stockholm/O=himinds/OU=Server/CN=$IP"
SUBJECT_CLIENT="/C=SE/ST=Stockholm/L=Stockholm/O=himinds/OU=Client/CN=$IP"

function generate_CA () {
   echo "$SUBJECT_CA"
   openssl req -x509 -nodes -sha256 -newkey rsa:2048 -subj "$SUBJECT_CA"  -days 365 -keyout ca.key -out ca.crt

tmckayus

Overview: running crc on a remote server

This document shows how to deploy an OpenShift instance on a server using CodeReady Containers (crc) that can be accessed remotely from one or more client machines (sometimes called a "headless" instance). This provides a low-cost test and development platform that can be shared by developers. Deploying this way also allows a user to create an instance that uses more cpu and memory resources than may be available on his or her laptop.

While there are benefits to this type of deployment, please note that the primary use case for crc is to deploy a local OpenShift instance on a workstation or laptop and access it directly from the same machine. The headless setup is configured completely outside of crc itself, and supporting a headless setup is beyond the mission of the crc development team. Please do not ask for changes to crc to support this type of deployment, it will only cost the team time as they politely decline :)

The instructions here were tested with F

willthames

#!/bin/bash

set -eu

if [ $# -lt 2 ] ; then
    echo "Usage: $0 [--profile profile] [--region region] [--key key] [--filter filterkey] user host [port]"
    exit
fi

while true; do

sivel

---
- name: Playbook showcasing conversion from with_X loops to loop+filters
  hosts: localhost
  gather_facts: false
  vars:
    items:
      -
        - foo
      -
        - bar

eLement87

#include <FS.h>
#include <ESP8266WiFi.h>
#include <WiFiClientSecure.h>
#include <PubSubClient.h>
#include <time.h>

// Insert your FQDN of your MQTT Broker
#define MQTT_SERVER "mqtt.srvx1.local"
const char* mqtt_server = MQTT_SERVER;

bantya

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{0E270DAA-1BE6-48F2-AC49-4E2781B29975}]
@="Creative Cloud Files"
"System.IsPinnedToNameSpaceTree"=dword:00000000

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{0E270DAA-1BE6-48F2-AC49-4E2781B29975}]
@="Creative Cloud Files"
"System.IsPinnedToNameSpaceTree"=dword:00000000

gregelin

This note explains the common issue of "notapplicable" results when running openSCAP and SCAP-Security-Guide on CentOS.

SCAP seems like it should be easy because it is "just XML". Then you dig into looking for a test and it gets confusing fast. So it is good to have some background.

SCAP (Security Content Automation Protocol) is actually a set of multiple standards and specifications that are used together to enable automatically testing hundreds of nerd settings. Let me emphasize that: SCAP is not a single XML specification -- SCAP is multiple standards and specs. Whenever you give "SCAP Content" to a scanner to check a system configurations you are giving the scanner multiple XML files representing multiple standards.

oneohthree

echo "$STRING" | iconv -t ascii//TRANSLIT | sed -r s/[^a-zA-Z0-9]+/-/g | sed -r s/^-+\|-+$//g | tr A-Z a-z

mobilemind

# delete local tag '12345'
git tag -d 12345
# delete remote tag '12345' (eg, GitHub version too)
git push origin :refs/tags/12345
# alternative approach
git push --delete origin tagName
git tag -d tagName