.bat 혹은 .cmd 파일을 만들 때, 간혹 특수 문자가 포함되는 암호를 입력하게 할 때 그냥 그대로 입력하면 안될 때가 있다.

그 이유를 확인해본 결과 cmd.exe 내에서 특수 문자중 “%”와 “^” 때문이다.

%의 경우 간혹 환경변수 값 조회하는 구조와 유사할 경우 적용이 안되고, ^ 인 경우에는 아예 ESC 형태의 값이라고 파싱해서 발생되는 문제다.

%만 단독으로 쓰면 상관 없지만, %???% 로 쓰면 환경 변수로 치환된다. 
^인 경우에는 바로 뒤에 오는 글자가 ESC 로 전환되어 화면 표시 방법이 달라지게 된다.

이 경우 해결방법은 다음과 같다.

% –> ^%
^ –> ^^

위와 같이 변환을 하면 된다.

그러면 원하는 특수 문자가 화면에 제대로 표시된다.

2020. 4. 2. 오후 3:24

Original : https://www.freertos.org/FreeRTOS-Coding-Standard-and-Style-Guide.html

Kernel > About FreeRTOS Kernel > Coding, Testing, & Style

Coding Standard, Testing and Style Guide

On this page:

• Coding Standard
• Testing
• Naming Conventions
• Data Types
• Style Guide

Coding Standard / MISRA Compliance

The core FreeRTOS source files (those that are common to all ports, but not the port layer) conform to the MISRA coding standard guidelines. Compliance is checked using pc-lint with the linked lint configuration files. As the standard is many pages long, and is available for purchase from MISRA for a very small fee, we have not replicated all the rules here.

Deviations from the MISRA standard are listed below:

• Two API functions have more than one exit point. A deviation was permitted in these two cases for reasons of critical efficiency.
• When creating tasks, the source code manipulates memory addresses to locate the start and end addresses of the stack allocated to the created task. The code has to work for all the architectures to which FreeRTOS has been ported – which includes architectures with 8, 16, 20, 24 and 32-bit buses. This inevitably requires some pointer arithmetic. When pointer arithmetic is used, the arithmetic result is programatically checked for correctness.
• The trace macros are, by default, empty, so do not generate any code. Therefore, MISRA compliance checking is performed with dummy macro definitions.
• MISRA rules are turned off on a line by line basis, as deemed appropriate (that is, complying with the rule is deemed to create less appropriate code for a deaply embedded system than carefully not complying). Each such occurrence is accompanied by a justification using the special pc-lint MISRA comment mark-up syntax.

FreeRTOS builds with many different compilers, some of which are more advanced than others. For that reason FreeRTOS does not use any of the features or syntax that have been introduced to the C language by or since the C99 standard. The one exception to this is the use of the

stdint.h

header file. The

FreeRTOS/Source/include

directory contains a file called

stdint.readme

that can be renamed

stdint.h

to provide the minimum stdint type definitions necessary to build FreeRTOS – should your compiler not provide its own.

Testing

This section describes the tests performed on common code (the code located in the FreeRTOS/Source directory, that is built by all FreeRTOS kernel ports), and the tests performed on the portable layer code (the code located in subdirectories of the

FreeRTOS/Source/portable

directory).

• Common code

  The standard demo/test files attempt to provide ‘branch’ test coverage (in most cases this actually achieves ‘condition’ coverage because the kernel’s coding style deliberately keeps conditions simple specifically for this purpose), whereby tests ensure both ‘true’ and ‘false’ paths through each decision are exercised. ‘branch’ coverage is measured using GCOV by defining the mtCOVERAGE_TEST_MARKER() macro to a NOP (no operation) instruction in the ‘else’ path of each ‘if()’ condition if the ‘else’ path would otherwise be empty. mtCOVERAGE_TEST_MARKER() is only defined while measuring test coverage – normally it is an empty macro that does not generate any code.

• Port layer

  Port layer code is tested using ‘reg test’ tasks, and, for ports that support interrupt nesting, the ‘interrupt queue’ tasks.

  The ‘reg test’ tasks create multiple (normally two) tasks that first fill all the CPU registers with known values, then continuously check that every register maintains its expected known value as the other tests execute continuously (soak test). Each reg test task uses unique values.

  The ‘interrupt queue’ tasks perform tests on interrupts of different priorities that nest at least three deep. Macros are used to insert artificial delays into pertinent points within the code to ensure the desired test coverage is achieved.

It is worth noting that the thoroughness of these tests have been responsible for finding bugs in silicon on multiple occasions.

Naming Conventions

The RTOS kernel and demo application source code use the following conventions:

• Variables
  • Variables of type uint32_t are prefixed ul, where the ‘u’ denotes ‘unsigned’ and the ‘l’ denotes ‘long’.
  • Variables of type uint16_t are prefixed us, where the ‘u’ denotes ‘unsigned’ and the ‘s’ denotes ‘short’.
  • Variables of type uint8_t are prefixed uc, where the ‘u’ denotes ‘unsigned’ and the ‘c’ denotes ‘char’.
  • Variables of non stdint types are prefixed x. Examples include BaseType_t and TickType_t, which are portable layer defined typedefs for the natural or most efficient type for the architecture and the type used to hold the RTOS tick count respectively.
  • Unsigned variables of non stdint types have an additional prefix u. For example variables of type UBaseType_t (unsigned BaseType_t) are prefixed ux.
  • Variables of type size_t are also prefixed x.>
  • Enumerated variables are prefixed e
  • Pointers have an additional prefixed p, for example a pointer to a uint16_t will have prefix pus.
  • In line with MISRA guides, unqualified standard char types are only permitted to hold ASCII characters and are prefixed c.
  • In line with MISRA guides, variables of type char * are only permitted to hold pointers to ASCII strings and are prefixed pc.
• Functions
  • File scope static (private) functions are prefixed with prv.
  • API functions are prefixed with their return type, as per the convention defined for variables, with the addition of the prefix v for void.
  • API function names start with the name of the file in which they are defined. For example vTaskDelete is defined in tasks.c, and has a void return type.
• Macros
  • Macros are pre-fixed with the file in which they are defined. The pre-fix is lower case. For example, configUSE_PREEMPTION is defined in FreeRTOSConfig.h.
  • Other than the pre-fix, macros are written in all upper case, and use an underscore to separate words.

Data Types

Only stdint.h types and the RTOS’s own typedefs are used, with the following exceptions:

• char

  In line with MISRA guides, unqualified char types are permitted, but only when they are used to hold ASCII characters.

• char *

  In line with MISRA guides, unqualified character pointers are permitted, but only when they are used to point to ASCII strings. This removes the need to suppress benign compiler warnings when standard library functions that expect char * parameters are used, especially considering some compilers default unqualified char types to be signed while other compilers default unqualified char types to be unsigned.

There are four types that are defined for each port. These are:

• TickType_t

  If configUSE_16_BIT_TICKS is set to non-zero (true), then TickType_t is defined to be an unsigned 16-bit type. If configUSE_16_BIT_TICKS is set to zero (false), then TickType_t is defined to be an unsigned 32-bit type. See the customisation section of the API documentation for full information.

  32-bit architectures should always set configUSE_16_BIT_TICKS to 0.

   

• BaseType_t

  This is defined to be the most efficient, natural, type for the architecture. For example, on a 32-bit architecture BaseType_t will be defined to be a 32-bit type. On a 16-bit architecture BaseType_t will be defined to be a 16-bit type. If BaseType_t is define to char then particular care must be taken to ensure signed chars are used for function return values that can be negative to indicate an error.

• UBaseType_t

  This is an unsigned BaseType_t.

• StackType_t

  Defined to the type used by the architecture for items stored on the stack. Normally this would be a 16-bit type on 16-bit architectures and a 32-bit type on 32-bit architectures, although there are some exceptions. Used internally be FreeRTOS.

•  

Style Guide

• Indentation

  Tab characters are used to indent. One tab equals four spaces.

• Comments

  Comments never pass column 80, unless they follow, and describe, a parameter.

  C++ style double slash (//) comments are not used.

   

• Layout

  The FreeRTOS source code lay out is designed to be as easy to view and read as possible. The code snippets below show first the file layout, then the C code formatting.

  /* Library includes come first… */
  #include <stdlib.h>
  /* …followed by FreeRTOS includes… */
  #include “FreeRTOS.h”
  /* …followed by other includes. */
  #include “HardwareSpecifics.h”
  /* #defines comes next, bracketed where possible. */
  #define A_DEFINITION	( 1 )
  
  /*
   * Static (file private) function prototypes appear next, with comments
   * in this style – with each line starting with a ‘*’.
   */
  static void prvAFunction( uint32_t ulParameter );
  
  /* File scope variables are the last thing before the function definitions.
  Comments for variables are in this style (without each line starting with
  a ‘*’). */
  static BaseType_t xMyVariable.
  
  /* The following separate is used after the closing bracket of each function,
  with a blank line following before the start of the next function definition. */
  
  /*———————————————————–*/
  
  void vAFunction( void )
  {
      /* Function definition goes here – note the separator after the closing
      curly bracket. */
  }
  /*———————————————————–*/
  
  static UBaseType_t prvNextFunction( void )
  {
      /* Function definition goes here. */
  }
  /*———————————————————–*/
  
  File Layout

  
  
  

  /* Function names are always written on a single line, including the return
  type.  As always, there is no space before the opening parenthesis.  There
  is a space after an opening parenthesis.  There is a space before a closing
  parenthesis.  There is a space after each comma.  Parameters are given
  verbose, descriptive names (unlike this example!).  The opening and closing
  curly brackets appear on their own lines, lined up underneath each other. */
  void vAnExampleFunction( long lParameter1, unsigned short usParameter2 )
  {
  /* Variable declarations are not indented. */
  uint8_t ucByte;
  
      /* Code is indented.  Curly brackets are always on their own lines
      and lined up underneath each other. */
      for( ucByte = 0U; ucByte < fileBUFFER_LENGTH; ucByte++ )
      {
          /* Indent again. */
      }
  }
  
  /* For, while, do and if constructs follow a similar pattern.  There is no
  space before the opening parenthesis.  There is a space after an opening
  parenthesis.  There is a space before a closing parenthesis.  There is a
  space after each semicolon (if there are any).  There are spaces before and
  after each operator.  No reliance is placed on operator precedence –
  parenthesis are always used to make precedence explicit.  Magic numbers,
  other than zero, are always replaced with a constant or #defined constant.
  The opening and closing curly brackets appear on their own lines. */
  for( ucByte = 0U; ucByte < fileBUFFER_LENGTH; ucByte++ )
  {
  }
  
  while( ucByte < fileBUFFER_LENGTH )
  {
  }
  
  /*  There must be no reliance on operator precedence – every condition in a
  multi-condition decision must uniquely be bracketed, as must all
  sub-expressions. */
  if( ( ucByte < fileBUFFER_LENGTH ) && ( ucByte != 0U ) )
  {
      /* Example of no reliance on operator precedence! */
      ulResult = ( ( ulValue1 + ulValue2 ) – ulValue3 ) * ulValue4;
  }
  
  /* Conditional compilations are laid out and indented as per any
  other code. */
  #if( configUSE_TRACE_FACILITY == 1 )
  {
      /* Add a counter into the TCB for tracing only. */
      pxNewTCB->uxTCBNumber = uxTaskNumber;
  }
  #endif
  
  A space is placed after an opening square bracket, and before a closing
  square bracket. 
  ucBuffer[ 0 ] = 0U;
  ucBuffer[ fileBUFFER_LENGTH – 1U ] = 0U;
  
  Formatting of C Constructs

•  

2020. 3. 24. 오후 1:29

Original : https://www.freertos.org/RTOS.html

Kernel > About FreeRTOS Kernel

The FreeRTOS™ Kernel

마켓 리딩, 사실상 표준, 크로스 플랫폼 RTOS 커널

15년 넘게 세계 대표 칩 회사 간의 파트너쉽 속에서 개발된 FreeRTOS 는 마이크로 컨트롤로 및 작은 마이크로프로세서용 마켓 리딩하는 리얼타임 OS(RTOS)이다. MIT 오픈 소스 라이선스 하에서 자유롭게 배포된 FreeRTOS는 커널을 포함해 전방위적인 산업에 걸처 다양한 라이브러리가 만들어지고 확대 적용되고 있다.  하루 평균 500회 다운로드 되고 있는 FreeRTOS는 안정성, 접근성 및 사용 편의성을 기준으로 구성되었습니다. 

알고 있나요?

FreeRTOS 는 하루 평균 500회의 다운로드를 기록하고 있음 (2018년 기준).

FreeRTOS 는 2011동안모든 EETimes Embeded Market Suvey 내 교육 클래스 중 최고의 자리에 올랐읍니다.

FreeRTOS 는 타 상업용 RTOS에 비해 낮은 프로젝트 위험도 및 소유에 대한 전체 비용을 낮추는데 도움을 드립니다.그 이유는 다음과 같습니다.:

• 전체적인 지원 및 문서화가 되어 있습니다.
• 대부분은 우리와의 연락없이도 시장에 제품을 출시해도 됩니다. 다만, 완벽한 마음의 평화가 필요하시다면, 언제든지 완전 면책형 상업라이선스(직접적 지원을 포함)으로 전환할 수 있는 변경도 가능합니다.

일부 FreeRTOS ports never completely disable interrupts.

For strict quality control purposes, and to remove all IP ownership ambiguity, official FreeRTOS code is separated from community contributions.

FreeRTOS has a tick-less mode to directly support low power applications.

FreeRTOS is designed to be simple and easy to use: Only 3 source files that are common to all RTOS ports, and one microcontroller specific source file are required, and its API is designed to be simple and intuitive.

The RL78 port can create 13 tasks, 2 queues and 4 software timers in under 4K bytes of RAM!

Why choose FreeRTOS?

“It’s probably safe to say at this point that FreeRTOS goes through more ‘peer-review’ than any other RTOS available on the planet. I have used it in several projects – one of which was a multiprocessor environment that used more than 64 processors and needed to run for months reliably. The RTOS core performed well. Take FreeRTOS for a spin.” – John Westmoreland

FreeRTOS provides the best of all worlds: FreeRTOS is truly free and supported, even when used in commercial applications. The FreeRTOS open source MIT license does not require you to expose your proprietary IP. You can take a product to market using FreeRTOS without even talking to us, let alone paying any fees, and thousands of people do just that. If, at any time, you would like to receive additional backup, or if your legal team require additional written guarantees or indemnification, then there is a simple low cost commercial upgrade path. Your peace of mind comes with the knowledge that you can opt to take the commercial route at any time you choose.

Here are some reasons why FreeRTOS is a good choice for your next application – FreeRTOS…

• Provides a single and independent solution for many different architectures and development tools.
• Is known to be reliable. Confidence is assured by the activities undertaken by the SafeRTOS sister project.
• Is feature rich and still undergoing continuous active development.
• Has a minimal ROM, RAM and processing overhead. Typically an RTOS kernel binary image will be in the region of 6K to 12K bytes.
• Is very simple – the core of the RTOS kernel is contained in only 3 C files. The majority of the many files included in the .zip file download relate only to the numerous demonstration applications.
• Is truly free for use in commercial applications (see license conditions for details).
• Has commercial licensing, professional support and porting services available in the form of OPENRTOS from our partner WITTENSTEIN high integrity systems.
• Has a migration path to SafeRTOS, which includes certifications for the medical, automotive and industrial sectors.
• Is well established with a large and ever growing user base.
• Contains a pre-configured example for each port. No need to figure out how to setup a project – just download and compile!
• Has an excellent, monitored, and active free support forum.
• Has the assurance that commercial support is available should it be required.
• Provides ample documentation.
• Is very scalable, simple and easy to use.
• FreeRTOS offers a smaller and easier real time processing alternative for applications where eCOS, embedded Linux (or Real Time Linux) and even uCLinux won’t fit, are not appropriate, or are not available.

2020. 3. 24. 오후 1:22

log4net의 설정방법은 매우 다양하고 많다.

이중 가장 기본적인 설정 방법을 설명한다. nuget을 이용하여 개발하는 경우가 있는데, 이는 개발자가 모두 인터넷에 잘 연결된 사용자들이나 쓰는 방법이고, Offline 환경에서는 잘 맞지 않는다. 특히나 공동 작업일 때는 package 폴더도 공유해야 하는데, 이게 사이즈가…

여기서는 Assembly DLL 만 연결하는 방법으로 소개한다.

Assembly 폴더 만들고 log4net.dll 복사하기.

제일 먼저 하는 것은 Solution 폴더 위치에 Assembly라는 폴더를 만든다. 보통 Visual Studio를 써서 프로젝트를 만들면 Solution 폴더 하위에 Project 폴더들이 박히는데, 여러 개의 Project를 만든 후 모든 Project들이 log4net을 쓴다면, 이 방법이 제일 좋은 것 같다.

그 안에 log4net.dll 을 복사해서 넣는다.

Project 내 참조 추가.

Project 폴더 내에 있는 참조 위에서 참조추가를 시도한다.

참조 폴더에서 위에 넣었던 파일을 Browse로 찾아서 넣도록 한다. 만일 캐쉬로 있다고 해도 다른 위치의 파일일 수 있으니 반드시 직접 Browse 해서 찾아서 넣도록 한다. 그 이유는 여러개의 프로젝트 작업을 수행한 경우 파일 이름은 같을지 몰라도 전혀 다른 프로젝트의 DLL을 참조할 수 있다.

AssemblyInfo.cs 수정

Properties 폴더 안에 AssemblyInfo.cs 파일이 있는데 이 파일을 연다.

그 안에 여러가지 내용이 있지만, 맨 밑에다가 다음 한 줄을 추가한다.

[assembly: log4net.Config.XmlConfigurator(Watch = true)]

app.config 설정

이 부분은 내용이 참 많은데, 자세한 설명없이 단순하게 추가할 내용만 정리한다.

먼저 XML의 configuration 엘리멘트 안에 다음과 같은 섹션을 추가한다. 이전에 이미 만들어 넣었다면, section만 추가할 수도 있다. 이 항목이 들어가야 log4net 이라는 엘리멘트를 만들어 넣을 수 있다.

<configSections>
  <section name="log4net" type="System.Configuration.IgnoreSectionHandler"/>
</configSections>

section을 추가했다면 이제 아래 쪽에(보통은 appSettings 밑) 다음과 같은 항목을 추가한다.

<log4net>
  <appender name="Appender" type="log4net.Appender.RollingFileAppender">
    <file value="service.log"/>      
    <rollingStyle value="Date"/>      
    <datePattern value="_yyyyMMdd'.log'"/>
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="%date %-5level %logger - %message%newline"/>
    </layout>
    <lockingModel type="log4net.Appender.FileAppender+MinimalLock"/>
  </appender>    
  <root>
    <level value="ALL"/>
    <appender-ref ref="Appender"/>
  </root>
</log4net>

위와 같이 설정할 때, Appender 쪽만 잘 잡아주면 되는데, 파일 저장 위치나, 로그가 쌓일 때 텍스트 형식등을 정의할 수 있다. file과  conversionPatten 이라는 엘리멘트를 수정하면 된다.

log 개체 소스에 박기

실제 로그를 쌓기 위해 소스에 박기전에 각 소스 클래스 내 로그 관련 인스턴스를 생성한다. 그렇다고 매번 클래스 만들어질 때마다 만들 수 없으므로 1회안에 활성화 될 수 있도록 static 으로 구성한다.

모든 클래스 최 상단에 다음과 같은 코드를 담도록 한다.

private static readonly log4net.ILog log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

위와 같이 넣으면 코드안에서 다음과 같이 코드를 작성할 수 있다.

log.Error("Service started");

정리하며

매번 코드 내에 적용하면서 다른 프로젝트 내의 코드를 복사해서 처리하는 것만 했지 별도로 정리한적이 없어서 정리해봤다.

나중에, 설정 관련된 특이하게 응용했던 것들도 정리해보려고 한다.

2020. 3. 11. 오전 9:41

프로젝트를 수행을 한다고 할 때, 내 기준으로 볼 때, 각 개발자들의 개발 속도를 측정하는 일은 매우 중요하다. 각 개발자, 아니 자신에게 일이 맡겨졌을 때, 이 일을 해결하기 위해서는 어느정도의 시간이 필요한지를 알아야 계획을 잡고 업무를 수행할 수 있기 때문이다.종료일을 잡고 그 종료일에 맞게 수행하기 위해서 이다.

물론 S/W 관련 연구자들이나, 개발자 중심의 판단 보다, 영업적 판단, 경영적 판단을 중심으로 생각하는 경우 위와 같은 일정 수립에서는 선 설계를 통한 명확한 구분을 가져가는 것이 좋다고 판단하는 경우가 있다. 미리 설계를 하며, 각 설계의 내용을 명확히 하면 각 등급별 표준 등위에 따라 나누더라도 완벽하지는 않지만, 매우 높은 정확도를 갖는 개발 기간 산정이 가능하다고 믿고 있다.

하지만, 여기에는 설계의 함정이라고 생각하는 부분이 있다. 사실 S/W를 설계하는 작업 자체가 난이도가 매우 높은 작업이다. 그래서 무슨 H/W 의 도면이나, 건설 도면 같이 생각하고 각 내용들을 구분지어 할 수 있다고 믿는데, 실제 S/W 개발 중에 나오는 설계는 위에 언급한 도면과 같은 상세 설계가 아니라, 무엇을 개발할지에 대한 대략적인 개발  방향을 잡는 용도라고 본다.

만약 위에서 언급한 블루프린트 설계도 같이 작성을 하려면, 최소한 현재 업무에 대한 전체 공정에 5~60% 이상의 기여를 하고 이와 같은 공정 자체를 3번 이상 수행을 해야 설계가 나올 것 같다. (천재적이거나 광범위한 경험을 갖는 사람이면 위의 한계점이 무의미할 수 도 있겠지만;;;; )

예를 들어 금융 관련 시스템 개발을 3년 정도하고, 엘리베이터 제어 소프트웨어 개발을 1년 정도 한 개발자가, 어느날 국가 세금 관리 시스템을 만든다고 생각해보자. 대략적인 설계는 가능하다. S/W 공학에서 이야기하는 UML이나, 패키지라고 통칭되는 각종 개발 방법론에 의거한 관련 산출물은 만들 수 있다. 그런데 그 설계안 대로 개발을 할 수 있을까? 아니 그 설계도를 보면서 개발 관련된 종료시점을 예측할 수 있을까?

사람 머릿속에서 만들어지는 각종 아이디어를 아예 표준화하여 생각하는 것 자체를 통일시키거나(모든 사람의 머릿속 생각이 동기화되어 동일한 생각을 하게해주는?) 오롯히 혼자 개발하며 동시에 머릿속 생각이 바뀜이 전혀 없다면 가능하겠지만, 실제 현장에서는 중구난방이다. 벽돌이나 전자부품 처럼 표준이라는게 매우 불분명 하다. 그것을 맞춰보려 개발 표준안을 만들지만 어디까지나 권고 사항이고 생각하는 방식이나 표현 방식은 제각각이다.

결국 표준화되지 않는 개개인의 머릿속에서 탄생하기 때문에, 모든 산술적 데이터는 개개인에 맞추어 나와야 하며, 그래서 개개인의 개발 속도가 매우 중요하다고 본다. 즉 이 개발속도 라는 것을 통해 단위 단위를 개개인에게 맡기고 산정하여 합산 처리하면 분명한 완료 일자가 잡히게 된다.

완료 일정이 잡히면 분명한 단위 단위가 예측되며 이후 개발 계획이 설 수 있다.

물론 개발 속도는 개발 외적인 부분에서 사용되지 않도록 장치를 잘 갖추어야 한다. 만약 개발 속도를 개개인을 평가하는 기준이되거나 급여, 기여도 등에 미치지 않도록 해야 한다. 팀을 구성해 팀 단위의 평가 형태로 가져갈 수 있게 하는 등의 안전장치를 확보하고 개개인의 개발 속도에 대한 평가가 필요하다.

2020. 1. 16. 오전 12:08

Jenkins 에서 다양한 인증 기반을 구성할 수 있는데, 그 중 MS Windows에서 제공하는 Active Directory를 이용하는 방법이다.

일단, Jenkins 사이트에 접속한다.

그리고 난 뒤 왼편의 메뉴에서 "Jenkins 관리"를 선택한 뒤, "Configure Global Security"를 선택한다.

Configure Global Security 안에서 이번에는 "Enable security"를 체크한다.

그리고 난 뒤, Security Realm 안에서 LDAP을 선택한다.

그리고 난 뒤 다음과 같이 입력한다.

• Server : AD 서버의 주소를 넣는다.
• rootDN : LDAP 쿼리 형태로 경로를 넣는다. 해당 주소를 DC=xxxx, DC=yyyy 로 넣도록 한다. 만일 Domain Name이 testdomain.com 이라면, DC=testdomain, DC=com 으로 만들면 된다. 이 경로는 ADSI 라는 도구를 사용하면 간단하게 추출 가능하다.
• User search base : 사용자 계정들이 담긴 위치를 잡는다. 일단 rootDN을 기준으로 상대 위치를 잡는다. 만일 AD 상의 Users를 사용한다면 CN=Users 로 넣으면 된다.
• User search filter : 계정으로 사용할 id 부분인데, 이 부분은 sAMAccountName={0} 으로 한다. LDAP 상에 해당 개체의 속성 값 중, sAMAccountName 을 사용하면 된다.
• Manager DN : AD 쿼리를 할 때, 로그인을 해야만 접근이 가능한 경우에 넣는다. 관리자 계정에 대한 LDAP 쿼리용 주소값을 넣도록 한다. 위의 이미지를 기준으로 보면,  ????.local 도메인 안에 xxxxx\ServiceAccounts OU 안에 있는 yyyyy Admin. 이라는 계정을 사용할 때 사용한다.
• Manager Password : 위에서 결정한 관리자 계정에 대한 암호를 넣는다.

그리고 난 뒤, 밑에 위치한 "Test LDAP settings" 버튼을 눌러 AD 상의 계정으로 정상적으로 로그인 되는지 확인하도록 한다.

참고로 Authorization 안에 있는 항목을 세가지로 설정할 수 있는데, 선택에 따라 다음과 같다.

• Anyone can do anything : 모든 사용자가 뭐든지 할 수 있는 모드. 로그인이 필요 없기 때문에, 인터넷으로 연결된 곳에서는 쓸 수 없다.
• Legacy mode : 특정 사용자별로 권한을 설정할 때 사용하는데, 권한을 다양하게 설정해야 하는 경우 이 기능을 사용한다. 만일 개발팀 내에서만 쓴다면 이 모드는 설정을 귀찮게 한다.
• Logged-in users can do anything : 평등하게 로그인만 성공하면 무조건 모든지 쓸 수 있도록 한다.

2019. 12. 23. 오후 2:06

인터넷과 연결된 도메인서버인데 매번 시간이 느려지면서 정시가 되지 않는 문제가 있다.

이 문제를 해결하기 위해 google을 찾아본 결과 사이트를 찾을 수 있었다.

Domain환경에서의 서버시간 설정(NTP)

일단 방법은 간단하다.

먼저 도메인서버에서 관리자 권한의 Command Line을 띄운다.

그리고 다음과 같은 명령을 입력한다.

w32tm /config /manualpeerlist:"time.windows.com time.nist.gov pool.ntp.org,0x01" /reliable:yes /update

위의 내용 중 time.windows.com time.nist.gov pool.ntp.org 에만 수정해주면 된다. 저 안에 NTP 서버 이름을 변경/추가하면 된다. 위의 샘플에서는 총 3개의 NTP 서버를 등록한 것이다. 각 구분은 공백(" ") 으로 하면 된다.

최종적으로 확인하고 싶으면 regedit를 열어 다음 경로에서 찾아보면 된다.

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

2019. 12. 23. 오후 12:21

보통 마인크래프트는 Java 버전을 메인으로 하고 있어 Java 버전에 대한 다양한 리뷰, 서버 구축 등 많은 내용이 있다. 그런데, 메인으로 사용 중인 노트북의 경우 내장 그래픽이 Intel CPU에 탑재된 GPU였고, 안타깝게도, Direct-X에는 어느정도 친화적이였지만, OpenGL 기반의 3D에서는 성능이 그다지 좋지 못했다.

다행히 Windows 10 에서 제공하는 App Store에 등록된 Minecraft의 경우에는 Direct-X 기반으로 제작되어서 인지 매우 부드러운 움직임을 보여주었고, 생각보다 원활하게 동작했다.

문제는 다른 부분에서 발생되었다. 노트북에서 하다가, 핸드폰으로 좀 하다가, 데스크톱으로 하려다가 보니, 매번 월드 설정 파일을 Export 해야 되었고, 파일 공유를 위해 클라우드에 업로드 해서 공유해야 했다. 가끔 Export/Import를 까먹다가 보면 같은 게임인데도 결국 최종 작업을 했던 위치와 전혀 다른 이전 위치에서 시작하기도 했다. 더욱이 다양한 작업을 하다가 노트북을 Reset을 했는데, 그만 백업을 안해서 기존 월드 정보가 깡그리 사라지는 일까지 벌어졌다.

그래서 아예 서버를 구축해서 그 내용을 공유해서 쓰면 되겠다 싶었다. 그래서 이미 다른 사람들이 Open 한 곳으로 접속을 하려는데, 왠걸... 가끔은 장시간 연결이 안될 때도 생기고, 월드가 사라지고, 좀 접속자들이 많은 것은 마인크래프트가 아닌 전혀 다른 형태의 게임이 만들어져서 뭔가 수익모델 창출하듯 이상한 작업을 요구했다. 집 짓고 놀고 싶으면 코인 만들어야 되었다.

그래서 내 서버를 구축해야 겠다는 생각을 했다.

최초는 Mojang 사이트에서 공식적으로 제공하는 서버를 받아서 설치했다. 그런데, 문제는 이 서버는 오로지 Java 버전의 클라이언트에서만 사용이 가능했다. 즉 공식 버전 서버는 내 Windows 10 버전의 클라이언트로는 접속이 안된다. 나중에 알고 보니, 마인크래프트는 크게 Java Edition과 Bedrock Edition 으로 나뉘고 대부분 Windows 10, XBox, Android 폰용 마인크래프트는 Bedrock 에 해당되었다. 결국 공식 서버로는 방법이 없다는 것을 깨달았다.

그래서 이번에는 google을 통해서 MCPE(Mine Craft Pocket Edition) 으로 검색했다. Bedrock Edition을 Pocket Edition 이라고도 지칭하는 것을 보고 검색해봤다. 그러자 여러가지 종류들의 서버들을 볼 수 있었다. 다만, 주류가 PHP 기반으로 된 PocketMin-MP 라고 듣게 되었고, 그 버전으로 찾았다.

맨 처음은 Nukkit 이라는 서버. 이 서버는 태생이 PocketMine-MP 라는 서버의 PHP 버전을 Java로 마이그레이션 한 버전이라고 했고, Java 여서 Windows 든 Linux든 적용하는데 어렵지 않다고 했다. 그래서 다운로드를 받고 Java로 띄우긴했는데, 생각보다 서버의 리소스 소모가 컸다. 뭐 커봐야 8G 램 안 쪽이고, i5 5세대 정도면 나름 훌륭한 PC라서, 큰 문제가 없을거라 생각했는데, , 제일 큰 문제는 게임이 계속 끊긴다는 점이였다. 부속을 뽀갰더니 갑자기 롤백되서 원래대로 돌아오고, 아이템을 옮겼는데, 다시 원상복귀되고, 이게 잘 되다가 갑자기 잘 안되기도 하고...

다음에는 아예 PocketMine-MP 를 직접 받아서 해봤다. PHP 의 Zend로 구성되어 있는데, 요즘은 아예 웹사이트 상에서 Linux 기반의 스크립트로 자동 설치를 구성해서 제공했다. 한국 내에서는 대부분 서버가 이 PcketMine-MP로 되어있고, 다양한 플러그인을 제공한다고까지 했다. 물론 난 실행을 해보는게 중요해 설치에 들어갔다. 몇가지 옵션 잡고 Start 하면 자동으로 PHP를 기반으로 띄워 주었다. 매우 기민하게 작동하였다. 그래서 LAN 상에서 직접 Windows 10 클라이언트로 연결해서 확인했는데, 뭘 부수던 깨던 바로 바로 반응하는 아름다운 모습을 보여주었다. 아이템 옮겨도 즉시 즉시 여기저기 뛰어 다녀도 드라마틱하게 동작했다. 그래서 이번에는 외부에서도 할 수 있도록 하는데... 기본 포트는 19132 를 Port-Forward 시키는데.. 안된다.로컬에서는 다 되었는데...

방화벽을 내릴까라는 심각한 고민을 할 정도로 여러가지를 봤는데, 알고보니, TCP만 쓰는게 아니라, UDP로 사용하는 구조였다. 방화벽에서 TCP/UDP 혹은 Both. 지원하지 않으면 TCP로 한번, UDP로 한번 해서 정책을 만들어주어야 했다. 그래서 간신히 외부에서 연결했고.. 슬슬 시동을 걸어보았다.

그런데... 이게 웃기는게 몬스터든, 동물이든 도통 Spawn 되지 않았다. 지도를 거의 1000단위로로 위치를 이동했는데, 나와주질 않았다. 도대체 어디까지 가야 하는지... 원.

그러다가 알게되었다. 이 PocketMine-MP는 원래 스마트폰 안에서 실행할 수 있도록 만든 매우 작은 사이즈의 서버였고, 몬스터나 동물의 Spawn은 서버의 리소스를 많이 잡아 먹기 대문에, PocketMine-MP에서는 해당 기능이 동작하지 않았다. 이것도 다양하게 검색을 해봤는데, 대부분의 답변은 PureEntitiesX 라는 플러그인을 설치해서 설정하라는 것이였다. 즉 플러그인을 추가해서 해당 기능을 동작하게 끔 하는게 유일하다고 했다. 그래서 부랴 부랴 설치해서 해봤는데, 게임 내 하루가 지나자 동물이 생성되고, 야간이 되자 몬스터들이 나타나기 시작했다. 여기까지는 딱 좋았다. 문제는 몹이나 동물이나 모두 바보였다. 벽에 부딪히자 몸으로 비비면서 떨어지질 않았고, 나를 향해 제대로 달려들지도 못했다.

결론적으로는 이 PocketMine-MP는 쓸모가 없었다. 거의 포기 할 즈음 게임피아라는 사이트에 있는 마인크래프트용 Wiki에 갔고, 그 중 Bedrock Deicated Server라는 문서를 보게 되었다. 그 중 리눅스 용으로 Open Source화된 서버를 알게 되었고, 그 서버 이름이 MinecraftBedrockServer 였다. 공식 사이트는 https://github.com/TheRemote/MinecraftBedrockServer 였다. 문제는 설치 방법이 없어서 해당 블로그를 찾게 되었고, 그 블로그가 https://jamesachambers.com/minecraft-bedrock-edition-ubuntu-dedicated-server-guide/ 였다.

먼저 Ubuntu와 같은 좀 메이저한 리눅스를 준비하고, 접속하는 사람에 따라 서버 H/W 사양을 좀 높이면 된다. 나야 혼자 할 것이라, 더 많이 낮은 PC에 구축했다.

방법은 아래와 같이 간단하다.

다음 명령을 한 줄 씩 실행한다. 설치용 스크립트 파일을 받아, 실행하는 작업이다.

wget https://raw.githubusercontent.com/TheRemote/MinecraftBedrockServer/master/SetupMinecraft.sh
chmod +x SetupMinecraft.sh
./SetupMinecraft.sh 

설치 중에 관리자 권한이 일시적으로 필요해기 때문에, sudo 할 수 있는 계정이여야 한다. 일단 권한 상승을 위한 암호를 입력하면 설치를 쭉하다가 몇가지 묻는다.

“Start Minecraft server at startup automatically (y/n)?” 라고 묻는다면, y를 택한다. 서버를 진짜 백그라운드 서비스를 만들어준다. 이게 활성화되면, 굳이 로그인해서 프로그램을 일일히 실행안해도 되고, 계정 로그 아웃되어도 실행된 상태를 유지한다.

“Automatically restart and backup server at 4am daily (y/n)?” 라고 묻는다면, 이 역시 y를 택한다. 매일 새벽 4가 되면, 자동으로 재부팅하고 백업을 해준다는 의미다. 중요하지 않아도 서버가 깨졌을 때, 복구하는데 큰 도움이 된다.

자 그러면 자동으로 이 서버의 서비스가 실행되고, Windows 10용 클라이언트로 접속해보았다. 19132 로 접속하자 딱 붙고 상태도 나온다.

더 감동적인 사실은 "벌꿀"이 보였다. 최신 버전의 스킨에서 나온다는 벌꿀이.. 게다가 주변에는 각종 동물이 나돌아 다녔고, 이 글을 쓴다고 방치해놓자, 어느새 다가온 몹에 쳐발렸다. 부활해서 잠깐 주변을 이리저리 살펴보자 좀비에 거미에 ...

이제 이 곳에 정착하면서 다시 집짓고 서바이벌 놀이를 해봐야 겠다.

2019. 12. 20. 오후 4:51