NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MariaDB to secure it, we'll need the current password for the root user. If you've just installed MariaDB, and haven't set the root password yet, you should just press enter here.
Enter current password for root (enter for none): OK, successfully used password, moving on...
Setting the root password or using the unix_socket ensures that nobody can log into the MariaDB root user without the proper authorisation.
You already have your root account protected, so you can safely answer 'n'.
You already have your root account protected, so you can safely answer 'n'.
Change the root password? [Y/n] New password: Re-enter new password: Password updated successfully! Reloading privilege tables.. ... Success!
By default, a MariaDB installation has an anonymous user, allowing anyone to log into MariaDB without having to have a user account created for them. This is intended only for testing, and to make the installation go a bit smoother. You should remove them before moving into a production environment.
Remove anonymous users? [Y/n] ... Success!
Normally, root should only be allowed to connect from 'localhost'. This ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] y ... Success!
By default, MariaDB comes with a database named 'test' that anyone can access. This is also intended only for testing, and should be removed before moving into a production environment.
Remove test database and access to it? [Y/n] y - Dropping test database... ... Success! - Removing privileges on test database... ... Success!
Reloading the privilege tables will ensure that all changes made so far will take effect immediately.
Reload privilege tables now? [Y/n] y ... Success!
Cleaning up...
All done! If you've completed all of the above steps, your MariaDB installation should now be secure.
$ minicom --help Usage: minicom [OPTION]... [configuration] A terminal program for Linux and other unix-like systems.
-b, --baudrate : set baudrate (ignore the value from config) -D, --device : set device name (ignore the value from config) -s, --setup : enter setup mode -o, --noinit : do not initialize modem & lockfiles at startup -m, --metakey : use meta or alt key for commands -M, --metakey8 : use 8bit meta key for commands -l, --ansi : literal; assume screen uses non IBM-PC character set -L, --iso : don't assume screen uses ISO8859 -w, --wrap : Linewrap on -H, --displayhex : display output in hex -z, --statline : try to use terminal's status line -7, --7bit : force 7bit mode -8, --8bit : force 8bit mode -c, --color=on/off : ANSI style color usage on or off -a, --attrib=on/off : use reverse or highlight attributes on or off -t, --term=TERM : override TERM environment variable -S, --script=SCRIPT : run SCRIPT at startup -d, --dial=ENTRY : dial ENTRY from the dialing directory -p, --ptty=TTYP : connect to pseudo terminal -C, --capturefile=FILE : start capturing to FILE -F, --statlinefmt : format of status line -R, --remotecharset : character set of communication partner -v, --version : output version information and exit -h, --help : show help configuration : configuration file to use
These options can also be specified in the MINICOM environment variable. This variable is currently unset. The configuration directory for the access file and the configurations is compiled to /etc/minicom.
Report bugs to <minicom-devel@lists.alioth.debian.org>.
When an atomic commit fails then the output will be stuck in REPAINT_AWAITING_COMPLETION state. It is waiting for a vblank event that was never scheduled. If the error is EBUSY then it can be expected to be a transient error. So propagate the error and schedule a new repaint in the core compositor.
This is necessary because there are some circumstances when the commit can fail unexpectedly: - With 'state_invalid == true' one commit will disable all planes. If another commit for a different output is triggered immediately afterwards, then this commit can temporarily fail with EBUSY because it tries to use the same planes. - At least with i915, if one commit enables an output then a second commit for a different output immediately afterwards can temporarily fail with EBUSY. This is probably caused by some hardware interdependency. Signed-off-by: Michael Olbrich's avatarMichael Olbrich <m.olbrich@pengutronix.de>
libweston/backend-drm/drm.c의 drm_repaint_flush()와
libweston/compositor.c의 output_repaint_timer_hander() 쪽에 수정이 가해진다.
WL_EXPORT void weston_output_disable_planes_incr(struct weston_output *output) { output->disable_planes++; /* * If disable_planes changes from 0 to non-zero, it means some type of * recording of content has started, and therefore protection level of * the protected surfaces must be updated to avoid the recording of * the protected content. */ if (output->disable_planes == 1) weston_schedule_surface_protection_update(output->compositor); }
struct content_protection은 누가 만드나 하면서 따라가보니
weston_compositor_enable_content_protection() 함수에서 만들어 주고 해당 함수는
//git\libweston\content-protection.c WL_EXPORT int weston_compositor_enable_content_protection(struct weston_compositor *compositor) { struct content_protection *cp;
C Specification void glReadPixels( GLint x, GLint y, GLsizei width, GLsizei height, GLenum format, GLenum type, GLvoid * data); Parameters x, y Specify the window coordinates of the first pixel that is read from the frame buffer. This location is the lower left corner of a rectangular block of pixels.
width, height Specify the dimensions of the pixel rectangle. width and height of one correspond to a single pixel.
24/03/2021 11:09:19 Pixel format for client 192.168.0.6: 24/03/2021 11:09:19 87 bpp, depth 5, little endian 24/03/2021 11:09:19 true colour: max r 47360 g 20997 b 2, shift r 179 g 0 b 77 24/03/2021 11:09:19 rfbSetTranslateFunction: client bits per pixel not 8, 16 or 32 24/03/2021 11:09:19 Client 192.168.0.6 gone
/* This call creates a mask and then a cursor: */ /* rfbScreen->defaultCursor = rfbMakeXCursor(exampleCursorWidth,exampleCursorHeight,exampleCursor,0); */
MakeRichCursor(rfbScreen);
/* initialize the server */ rfbInitServer(rfbScreen);
#ifndef BACKGROUND_LOOP_TEST #ifdef USE_OWN_LOOP { int i; for(i=0;rfbIsActive(rfbScreen);i++) { fprintf(stderr,"%d\r",i); rfbProcessEvents(rfbScreen,100000); } } #else /* this is the blocking event loop, i.e. it never returns */ /* 40000 are the microseconds to wait on select(), i.e. 0.04 seconds */ rfbRunEventLoop(rfbScreen,40000,FALSE); #endif /* OWN LOOP */ #else #if !defined(LIBVNCSERVER_HAVE_LIBPTHREAD) && !defined(LIBVNCSERVER_HAVE_WIN32THREADS) #error "I need pthreads or win32 threads for that." #endif /* catch Ctrl-C to set a flag for the main thread */ signal(SIGINT, intHandler); /* this is the non-blocking event loop; a background thread is started */ rfbRunEventLoop(rfbScreen,-1,TRUE); fprintf(stderr, "Running background loop...\n"); /* now we could do some cool things like rendering in idle time */ while (maintain_connection) { sleep(5); /* render(); */ } fprintf(stderr, "\nShutting down...\n"); rfbShutdownServer(rfbScreen, TRUE); #endif /* BACKGROUND_LOOP */
revind / revind.so / run / websockify 는 websockify 에서 나온거
libvncserver 와 noVNC와 websockify 의 조합으로 어찌 되긴 하는데..
~/libvncserver/webclients $ ls -al total 64 drwxr-xr-x 4 pi pi 4096 Aug 12 11:44 . drwxr-xr-x 16 pi pi 4096 Aug 12 11:03 .. -rwxr-xr-x 1 pi pi 25372 Aug 12 11:02 example -rw-r--r-- 1 pi pi 1601 Aug 12 10:32 index.vnc drwxr-xr-x 10 pi pi 4096 Aug 12 11:00 novnc -rwxr-xr-x 1 pi pi 424 Aug 12 11:39 rebind -rwxr-xr-x 1 pi pi 7508 Aug 12 11:39 rebind.so -rwxr-xr-x 1 pi pi 78 Aug 12 11:39 run drwxr-xr-x 3 pi pi 4096 Aug 12 11:28 websockify
인자는 아래와 같이 하고 실행!
$ ./run 5900 -- ./example
웹 브라우저에서 http://ip:5800 으로 접속하면 아래와 같이 뜨고
별다른 설정을 하지 않았다면 wss(websocket secure)를 안될테니 위에 "Click here to connect using noVNC"를 누른다.
약간의 시간을 기다리면(libvncserver의 웹 서버가 느린지 파일 전송이 좀 느리다)
아래와 같이 쨘~
+
한번 되더니 websockify 없이도 되네.. 머지?
+
runInBackground 의 값을 TRUE 로 해주면 웹 서버가 작동을 안한다 -_-
어떻게 해야 할까..
void rfbRunEventLoop ( rfbScreenInfoPtr screenInfo, long usec, rfbBool runInBackground )
static THREAD_ROUTINE_RETURN_TYPE listenerRun(void *data) { rfbScreenInfoPtr screen=(rfbScreenInfoPtr)data; int client_fd; struct sockaddr_storage peer; rfbClientPtr cl = NULL; socklen_t len; fd_set listen_fds; /* temp file descriptor list for select() */
/* Only checking socket state here and not using rfbIsActive() because: When rfbShutdownServer() is called by the client, it runs in the client-to-server thread's context, resulting in itself calling its own the pthread_join(), returning immediately, leaving the client-to-server thread to actually terminate _after_ the listener thread is terminated, leaving the client list still populated. */ /* TODO: HTTP is not handled */ }
