UICollectionView에 대해서 공부하던 중에,

https://theswiftdev.com/ultimate-uicollectionview-guide-with-ios-examples-written-in-swift/

 

위 포스트를 보게 되었고, 이분이 만든 CollectionView 프레임워크를 분석해보자고 마음 먹었다.

사실.. CollectionView 사용법이 나한테는 생각보다 어렵게 느껴져서,

이분이 만든 프레임워크와 예제를 분석하다 보면, 쉽게 이해될 수도 있을 것 같다는 조금의 희망을 가지고 시작한거다.

겸사겸사 swift 공부도 해볼겸..

 

그러다가, 아래와 같은 코드를 만나게 되었는데,

open 이라는 키워드를 처음 본 것 같아서, 이참에 알아봐야겠다 싶었다.

open class CollectionView: UICollectionView {

    open var source: Source? = nil {
        didSet {
            self.source?.register(itemsFor: self)

            self.dataSource = self.source
            self.delegate = self.source
        }
    }
}

 

https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html#//apple_ref/doc/uid/TP40014097-CH41-ID3

Swift 문서에서 이런걸 찾게 되었다.

Access Levels

Swift provides five different access levels for entities within your code. These access levels are relative to the source file in which an entity is defined, and also relative to the module that source file belongs to.

  • Open access and public access enable entities to be used within any source file from their defining module, and also in a source file from another module that imports the defining module. You typically use open or public access when specifying the public interface to a framework. The difference between open and public access is described below.
  • Internal access enables entities to be used within any source file from their defining module, but not in any source file outside of that module. You typically use internal access when defining an app’s or a framework’s internal structure.
  • File-private access restricts the use of an entity to its own defining source file. Use file-private access to hide the implementation details of a specific piece of functionality when those details are used within an entire file.
  • Private access restricts the use of an entity to the enclosing declaration, and to extensions of that declaration that are in the same file. Use private access to hide the implementation details of a specific piece of functionality when those details are used only within a single declaration.

Open access is the highest (least restrictive) access level and private access is the lowest (most restrictive) access level.

Open access applies only to classes and class members, and it differs from public access by allowing code outside the module to subclass and override, as discussed below in Subclassing. Marking a class as open explicitly indicates that you’ve considered the impact of code from other modules using that class as a superclass, and that you’ve designed your class’s code accordingly.

 

----------

 

Swift에는 5가지 접근 레벨이 있다.

5가지 레벨에는 open, public, internal access, file-private, private 가 있다.

 

위의 영어로 entities라고 있는데, 엔티티프로퍼티, 타입, 함수 등등을 이야기 한다고 합니다.

모듈(Module)은 쉽게 프레임워크라고 생각하면 좋을 것 같다.

 

open

- class에와 class member에만 사용할 수 있다.

- 모든 곳에서 sub classing이 가능하다.

 

public

- 클래스에 붙어있는 경우, 모듈 내에서만 sub classing이 가능하다.

 

Internal access

- 모듈 안에서 사용 가능

 

File-private

- 소스 파일 안에서만 사용 가능

 

private

- 소스 파일 안, 해당 선언 안에서만 사용 가능

파일만 변경

find ./ -type f -exec chmod -v 권한 {} \;
예: find ./ type f -exec chmod -v 755 {} \;

 

폴더만 변경

find ./ -type d -exec chmod -v 권한 {} \;
예: find ./ type d -exec chmod -v 755 {} \;

 

해당 파일만 변경

find ./ -type f -name 파일이름 -exec chmod -v 권한 {} \;
예: find ./ type f -name text.txt -exec chmod -v 755 {} \;

 

해당 파일을 제외하고 변경

find ./ -type f \! -name 파일이름 -exec chmod -v 권한 {} \;
예: find ./ type f \! -name text.txt -exec chmod -v 755 {} \;

 

해당 폴더만 변경

find ./ -type d -name 폴더이름 -exec chmod -v 권한 {} \;
예: find ./ type d -name testFolder -exec chmod -v 755 {} \;

 

해당 폴더를 제외하고 변경

find ./ -type d \! -name 폴더이름 -exec chmod -v 권한 {} \;
예: find ./ type d \! -name testFolder -exec chmod -v 755 {} \;

 

파일과 폴더 모두 변경

chmod -R 권한 *
예: chmod -R 755 *

관리자 페이지에 자신만의 메뉴를 추가하고 싶을때는,

add_menu_page() 함수를 사용하면 된다.

 

공식 문서를 확인해보면, (https://developer.wordpress.org/reference/functions/add_menu_page/)

add_menu_page( 
    string $page_title, 
    string $menu_title, 
    string $capability, 
    string $menu_slug, 
    callable $function = '', 
    string $icon_url = '', 
    int $position = null 
)

 add_menu_page 함수는 위와 같은 파라미터를 사용할 수 있다.

 

각 파라미터를 설명해보면

$page_title : add_menu_page 함수로 만들어진 페이지의 제목

$menu_title : 관리자 페이지에 표시될 메뉴 제목

$capability : 해당 메뉴를 볼 수 있는 사용자 권한  (https://wordpress.org/support/article/roles-and-capabilities/

$menu_slug : 만들어질 페이지의 slug, slub는 영어소문자, 숫자, -(하이픈) 으로만 구성 된다.

$function : 만들어질 페이지에 출력될 내용. 함수로 구현해도 된다. (예: echo "HIHI"; )

$icon_url : 해당 메뉴의 아이콘

$position : 해당 메뉴가 표시될 위치 설정  (아래 참조, 해당 숫자 사이사이를 입력하면 해당 메뉴 사이에 위치하게 된다.)

Default: bottom of menu structure #Default: bottom of menu structure
2 – Dashboard
4 – Separator
5 – Posts
10 – Media
15 – Links
20 – Pages
25 – Comments
59 – Separator
60 – Appearance
65 – Plugins
70 – Users
75 – Tools
80 – Settings
99 – Separator


For the Network Admin menu, the values are different: #For the Network Admin menu, the values are different:
2 – Dashboard
4 – Separator
5 – Sites
10 – Users
15 – Themes
20 – Plugins
25 – Settings
30 – Updates
99 – Separator

 

실 사용 예제

 function testPage() {
	 add_menu_page(
		 '테스트에용',
		 '테스트',
		 'manage_options',
		 'test-test',
		 'testPageFunction',
		 'dashicons-admin-generic',
		 81
	 );
 }
 add_action( 'admin_menu', 'testPage');

 function testPageFunction() {
	 get_template_part( 'admin-template-parts/test', 'test'  );
 }

위와 같은 함수를 현재 사용하고 있는 테마 폴더에 있는 functions.php 에 추가해준다.

그럼 '테스트' 라는 메뉴가 관리자 페이지에 생성되고,

해당 '테스트'라는 메뉴를 클릭하면,

해당 테마 폴더의 'admin-template-parts'라는 폴더안에 test-test.php 파일이 실행되면서 표시된다.

1. Certbot 설치

// add repo
$ sudo add-apt-repository ppa:certbot/certbot

// install certbot
$ sudo apt install python-certbot-nginx

 

2. HTTPS(SSL)을 설정할, nginx 설정 체크

// check server_name
$ sudo vi /etc/nginx/sites-available/example.com

// server_name example.com www.example.com;

 

3. nginx relaod

Certbot이 nginx 서버 블록을 확인하게 하기 위해, nginx reload

// reload nginx
$ sudo system reload nginx

 

 

4. 우분투 방화벽 (ufw)에서 https 허용

방확벽을 사용하지 않는다면, 따로 설정할 필요는 없지만,

기존에 방화벽을 사용하고 있다면, 아래 링크의 3단계를 참고해서 방화벽 설정을 진행한다.

 

참고 : https://velog.io/@pinot/Ubuntu-18.04%EC%97%90%EC%84%9C-Lets-Encrypt%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC-Nginx%EC%97%90-SSL%EC%9D%84-%EC%A0%81%EC%9A%A9%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95

 

번역) Ubuntu 18.04에서 Let's Encrypt를 사용하여 Nginx에 SSL을 적용하는 방법

우분투 환경에서 nginx에 certbot 클라이언트를 사용하여 자동적으로 SSL을 적용하는 방법에 대하여 알아보도록 합시다.

velog.io

 

5. HTTPS (SSL) 인증서 설치

$ sudo certbot --nginx -d example.com -d www.example.com

위의 명령어를 실행하면, 몇가지 과정을 진행 후, 아래와 같은 화면이 나온다.

Output
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
-------------------------------------------------------------------------------
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

// 1번은 http, https를 따로따로 접속할 수 있게 한다.
// 2번 설정은 http접속을 강제로 https로 모두 변경하므로 https접속만 할 수 있게 된다.

나는 2번을 선택했다.

원하는 번호를 선택하고, 엔터를 누르면 Nginx가 자동으로 재시작되고, 인증서가 저장된 위치를 알려주고, certbot은 종료된다.

 

6. Let's Encrypt HTTPS(SSL) 갱신

$ sudo certbot renew --dry-run

아주 간단하게, 위 명령어만 입력하면 certbot으로 진행한, HTTPS (SSL)을 모두 갱신할 수 있다.

 

Ubuntu Cron을 이용해서, 위의 갱신 명령어를 스케쥴링으로 하는 방법은 다음 포스팅에서...

 

 

참고 : https://velog.io/@pinot/Ubuntu-18.04%EC%97%90%EC%84%9C-Lets-Encrypt%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC-Nginx%EC%97%90-SSL%EC%9D%84-%EC%A0%81%EC%9A%A9%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95

* Ubuntu 18.04.4 LTS / Nginx 1.19.0 버전에서 테스트 했습니다.

* Ubuntu에 Nginx가 설치되어있다고 가정합니다.

 

필요 라이브러리 설치

apt-get install autotools-dev automake libtool m4 pkgconf libcurl4-openssl-dev libxml2 libxml2-dev libgeoip-dev libpcre3 libpcre3-dev zlib1g-dev g++

 

libmodsecurity 다운 및 컴파일


// Clone 
$ git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity

// Compile
$ cd ModSecurity
$ git submodule init && git submodule update && ./build.sh && ./configure && make && make install

 

Nginx connector 다운 및 컴파일

// Clone
$ git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git

// Check Nginx version
$ nginx -v

nginx version: nginx/1.19.0

// Nginx source code download
$ wget http://nginx.org/download/nginx-1.19.0.tar.gz

// Compile
$ cd nginx-1.19.0
$ ./configure --with-compat --add-dynamic-module=../ModSecurity-nginx
$ make modules

// copy object file
$ cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules

 

Nginx 모듈 로드

// /etc/nginx/nginx.conf

user nginx;

worker_processes auto;


# nginx module load -->
load_module "modules/ngx_http_modsecurity_module.so";



error_log /var/log/nginx/error.log  notice;

pid /var/run/nginx.pid;

 

ModSecurity 설정 -> 아래  업데이트 된, ModSecurity 설정 참고

// 1.추천 설정 다운로드
$ mkdir /etc/nginx/modsec

$ wget -P /etc/nginx/modsec/ https://raw.githubusercontent.com/SpiderLabs/ModSecurity/master/modsecurity.conf-recommended

$ mv /etc/nginx/modsec/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

// 2.“detection only” 모드에서 actively dropping traffic 로 변경
$ sed -i 's/SecRuleEngine DetectionOnly/SecRuleEngine On/' /etc/nginx/modsec/modsecurity.conf

// 3. SecRequestBodyInMemoryLimit 줄 제거

 

Nginx 설정

// active ModSeucrity in Nginx each site conf

server {
 ...
 
 modsecurity on;
 modsecurity_rules_file /etc/nginx/modsec/modsec_includes.conf;

 ...
}

// reload nginx
$ nginx -s reload 

 

참고 : https://itzone.tistory.com/707

 

--- 2020.07.24 업데이트 ---

위글 중, ModSecurity설정에서, 

https://raw.githubusercontent.com/SpiderLabs/ModSecurity/master/modsecurity.conf-recommended

위 주소가 404 NotFound로 나온다..

 

그래서 다른 방법을 찾아서 추가한다.

 

OWASP에서 제공하는 ModSecurity Core Rule Set을 이용한다.

https://owasp.org/www-project-modsecurity-core-rule-set/

 

ModSeucrity 설정

// OWASP Core Rule Set 사용
$ mkdir /etc/nginx/modsec

$ cd /etc/nginx/modsec

$ wget https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.1.0.tar.gz
$ tar -xvzf tar -xvzf v3.1.0.tar.gz
$ rm v3.1.0.tar.gz
$ cd v3.1.0.tar.gz/rules
$ cp REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
$ cp RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

$ cp /etc/nginx/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf
$ cp /etc/nginx/ModSecurity/unicode.mapping /etc/nginx/modsec/unicode.mapping

// make modsec conf and rules file
$ touch modsec_includes.conf

// write below in modsec_includes.conf
include modsecurity.conf
include owasp-modsecurity-crs/crs-setup.conf
include owasp-modsecurity-crs/rules/*.conf

// “detection only” 모드에서 actively dropping traffic 로 변경
$ sed -i 's/SecRuleEngine DetectionOnly/SecRuleEngine On/' /etc/nginx/modsec/modsecurity.conf

// SecRequestBodyInMemoryLimit 줄 제거

이전 OS X 버전에서의 설치방법은 많은데, 10.15 버전 설치방법은 별로 없어서, 기록해 놓는다.

Homebrew를 이용해서 설치했기 때문에, Homebrew를 먼저 설치한다.

 

1. Homebrew 설치

아래 코드를 터미널에 붙여넣기 한다.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

 

2. PHP 설치

brew install php

 

php 설치 후, php서비스를 시작해 준다.

brew services start php

 

그리고, 아마 기존에 있던 php 버전보다, 지금 설치한 php 버전이 더 높을테니, PHP FPM 버전을 지금 설치한 버전으로 변경해준다.

echo 'export PATH="/usr/local/opt/php/sbin:$PATH"' >> ~/.zshrc
source ~/.zshrc

 

2-1. 기존 php 삭제

brew를 이용해서, 삽질을 하다보면 여러 php가 설치될 수 있는데, 깔끔하게 지우고 시작하는게 좋다.

아래의 코드를 이용하자.

 

# Will show you any php packages you've got. make not of that!
brew list | grep php

# Will uninstall any php packages you may have
brew list | grep php | while read x; do brew uninstall --force $x; done

# You may need to run this too
rm -rf /usr/local/Cellar/php

# Clean up Launch Agents
rm ~/Library/LaunchAgents/homebrew.mxcl.php*
sudo rm /Library/LaunchDaemons/homebrew.mxcl.php*

brew untap homebrew/php
brew cleanup
brew update
brew doctor # just to make sure you're all clean

ps ax | grep php
# if some PHP daemons are still runing, reboot.

참고 URL : https://medium.com/@romaninsh/install-php-7-2-xdebug-on-macos-high-sierra-with-homebrew-july-2018-d7968fe7e8b8

 

3. Mariadb 설치

brew install mariadb

 

mariadb 설치 후, mariadb 서비스를 시작해준다.

brew services start mariadb

 

그리고, mariadb의 패스워드등을 설치하기 위해 아래 명령어를 실행시킨다.

sudo /usr/local/bin/mysql_secure_installation

 

4. nginx 설치

brew install nginx

 

nginx 설치 후, nginx 서비스를 시작한다.

brew services start nginx

 

nginx conf 파일을 열어준다.

vi /usr/local/etc/nginx/nginx.conf

 

nginx.conf 파일안에 server {} 부분은 모두 주석처리 해준다. 

nginx.conf
0.00MB

혹시 몰라서, 파일 업로드 해놓는다.

 

mkdir /usr/local/etc/nginx/servers/
cd /usr/local/etc/nginx/servers/
vi test.conf

 

servers 디렉토리를 만들고, test.conf 파일을 만든다.

#test.conf 파일
server {
    listen 8099;
    server_name localhost;
    root /Users/onsemiro/www/test;
    rewrite . /index.php;
    location / {
    index index.php index.html index.htm;
    autoindex on;
    }
    #proxy the php scripts to php-fpm
    location ~ \.php$ {
        include /usr/local/etc/nginx/fastcgi.conf;
        fastcgi_intercept_errors on;
        fastcgi_pass 127.0.0.1:9000;
    }
}

 

php 테스트 파일을 만들다.

vi /Users/onsemiro/www/test/index.php

#index.php 내용
<?php
	phpinfo();
?>

 

nginx를 재시작한다.

brew services restart nginx

 

http://localhost:8099/

에 접속해서 php 정보가 제대로 나오는지 확인해본다.

 

제대로 나오면 성공.

# http://github.com/mactsouk/go/simpleGitHub 패키치가 설치되어 있고, 해당 패키지를 삭제할 때.
# Step1. 중간 상태 파일 삭제
$ go clean -i -v -x github.com/mactsouk/go/simpleGitHub

# Step2. 로컬에 다운로드한 패키지 전체 삭제
$ rm -rf ~/go/src/github.com/mactsouk/go/simpleGitHub

 

AMD CPU에서는 잘 돌아가던 프로그램이, Intel CPU에서 실행하니까, 위와 같은 에러가 났다.

 

 

import encodings.idna

위 코드 한줄을 추가하고, 해결하였다.

 

 

참고 : https://stackoverflow.com/questions/9144724/unknown-encoding-idna-in-python-requests

+ Recent posts