Jump to content

Search the Community

Showing results for tags 'bsd'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Community
    • M2Dev
    • Offtopic
    • Games Talk
    • Music / Videos / Art
    • Member Representations
    • Services & Sales
  • Metin2
    • General
    • Questions and Answers
    • Frequently Asked Questions
    • Private Servers
    • Videos
  • Suggest a Tutorial / Release
    • Suggest a Tutorial / Release
    • Temporary forum
  • Releases
    • General
    • Guides & HowTo
    • Tools
    • Programming & Scripts / Systems
    • Maps
    • Quests
    • Binaries & Clients / ServerFiles
    • 3D Models
    • 2D Graphics
    • Operating Systems

Categories

There are no results to display.

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Nationality


Skype


Discord


Website


Steam ID


Mapping


3D


2D


C++


LUA


Python


PHP


SQL


HTML


CSS


JavaScript


Empire

Found 8 results

  1. I am looking for freeBSD 11.2 32 bits And also 11.2 64-bit Vdi format I hope to get them here in the forum Thank you
  2. Hi there, I'm sure you've found yourself into the situation where logs grow out of proportion and maybe fill your disk, especially if your metin2 server binary went into a loop of some kind. Or maybe your nginx or mysql logs grow so big that it takes 10 seconds just to open them. Of course you could just delete them and let them recreated, but a much cleaner solution is to let the syslog daemon keep your logs neatly ordered for you. For example, we can rotate the current log to a backup file (such as myserver.log.1) once it reaches a certain size, or we can do it every day, or every week; we can even use both criteria at the same time. Once the criteria is met for a second time, myserver.log will become myserver.log.1 and myserver.log.1 will become myserver.log.2, and so on. We can keep as many backups as we want too, and the oldest file will get deleted once rotation time comes. This ensures that the logs will never take more space on disk than the size limit we set, multiplied by the number of log files to keep. So let's say we want to rotate our metin2 server logs. First take a look at /etc/newsyslog.conf to see how it looks like. You can write directly to this file, but it would get overwritten when upgrading FreeBSD, so let's do this the proper way and create a new file called /etc/newsyslog.d/<application>.conf Each line corresponds to a log and each value is separated by a TAB: <location of the log file> <user:group> <mode> <logs to keep> <size limit> <time> <flags> <pid> Where user:group is the user owning the log file; mode the permissions set (such as 644); size limit is the size in kilobytes at which the log will be automatically rotated; time is a specially formatted string defining a time of the day, month or week for the logs to be rotated; flags define whether we want to compress the old logs and other options; and pid the path to the process id we have to signal. If this means nothing to you don't worry, I will give you a couple of ready made examples right now. Example A > Rotate game logs every time they grow to 4MB in size, keep 6 old logs, and compress them with gzip: ee /etc/newsyslog.d/metin2.conf /home/metin2/channel1/game1/syslog metin2:metin2 644 6 4096 * CZ /home/metin2/channel1/game1/pid.game /home/metin2/db/syslog metin2:metin2 644 6 4096 * CZ /home/metin2/db/pid.db (you can repeat this for each core) Example B > Rotate MySQL logs every monday at 4am, keep 3 old logs, and compress them with gzip: ee /etc/newsyslog.d/mysql.conf /var/db/mysql/myhostname.err mysql:mysql 644 3 @W1D4 * CZ /var/db/mysql/myhostname.pid Example C > Rotate NGINX logs every day at midnight, do not keep any old log: ee /etc/newsyslog.d/nginx.conf /var/log/nginx-access.log www:www 644 0 @T00 * C /var/run/nginx.pid /var/log/nginx-error.log www:www 644 0 @T00 * C /var/run/nginx.pid How do we know if we did it properly? Well, the system will send us a message if something is wrong, but only if we set a mail address for root mail to be forwarded to. By default FreeBSD sends error messages to the root account which we can read in the console using the "mail" command but since this is quite primitive let's have all mail sent to our e-mail: ee /etc/aliases Below this text: # Pretty much everything else in this file points to "root", so # you would do well in either reading root's mailbox or forwarding # root's email from here. Add this line, replacing the bracketed text with your email address: root:<your email here> Save and exit and then enter this command in the shell: newaliases Ready! Now you should receive system email in your own mailbox.
  3. If you have ever had an incident on your server - cores crashing, filesystem getting full, lag ingame, or ddos attacks- you know that it can turn into detective work to find what is wrong, especially when we don't have a degree in CS. There are some nifty command line monitoring tools (glances, htop, atop come to mind) but when you have several server machines it can get quite frantic and besides - those tools do not offer a lot of flexibility. As we progress in the path to become a skilled server administrator (understanding server as in the machine and the software installed on it rather than in the Metin2 sense), it becomes necessary to use a remote monitoring tool that gives us some visibility on our systems. There is a myriad of paid options featuring flashy animated dashboards out there, but they mostly belong to the cash cow realm of SaaS which I try to stay away of. So today I am going to introduce you to a free monitoring tool -monit- and to its paid console addon, which for some reason the programmers decided to name mmonit, creating unnecessary confusion. You may think that there is already enough documentation out there about popular tools like this - but you're wrong. As well crafted as monit and mmonit are, the documentation is somewhat obscure, particularly when it comes to FreeBSD. So I wanted to write down my experience in getting this tool to work in the best server operating system there is. Yeah, because as much as we like mocking the Ymir programmers, those who worked in the original version were not stupid at all, and the fact that they chose the rock solid FreeBSD -which was a relatively new system back then- is a good proof of that. Part A: Monit So let's get into action and introduce you to Monit. Monit is a very configurable daemon that can check virtually anything on our system -bandwidth, running processes, disk usage...- or even run custom scripts that extend its capabilities, and send us an e-mail to alert when, for example, we are running out of space, or our game server crashes. Nifty isn't it? Here's how an e-mail from monit looks: Connection failed Service nginx Date: Sat, 04 Apr 2020 18:05:26 Action: alert Host: host.myserver.com Description: failed protocol test [HTTP] at [www.myserver.com]:443 [TCP/IP TLS] -- HTTP: Error receiving data -- Operation timed out Your faithful employee, Monit Installing monit is easy - just run pkg install monit And then let's get our configuration ready. cp /usr/local/etc/monitrc.sample /usr/local/etc/monitrc ee /usr/local/etc/monitrc I will detail here the options we should concern ourselves about - you can leave the rest as default. First is the mail server which we are going to use to submit mail alerts; I entered here my own cPanel mailserver, where we previously whitelisted our IP (Exim Configuration/Access Control). If you don't have your own mail server, you can send the e-mail to sendmail on localhost. set mailserver mail.myserver.com, # primary mailserver localhost # fallback relay Next goes the e-mail address where we want to receive the alerts: set alert me@email.com not on { instance, action } And here we can configure the web interface. Here we set a port, user and password to connect. Simple isn't it? set httpd port 2812 and allow someuser:somepassword Finally we get to the substance - the monitoring rules. There are plenty of examples in the file, but I will drop my own configurations here as well, including a metin server which is what you're probably interested. This configuration is specific for FreeBSD (12 in my case but should be fine in any modern version) # Check overall system health check system $HOST if loadavg (1min) per core > 2 for 5 cycles then alert if loadavg (5min) per core > 1.5 for 10 cycles then alert if cpu usage > 75% for 2 cycles then alert if memory usage > 75% for 2 cycles then alert if swap usage > 75% for 2 cycles then alert # Web Server check process nginx with pidfile /var/run/nginx.pid start program = "/usr/local/etc/rc.d/nginx start" stop program = "/usr/local/etc/rc.d/nginx stop" if failed host www.mysite.com port 80 protocol http and request '/index.html' then alert if failed host patch.mysite.com port 80 protocol http and request '/index.php' then alert check process php-fpm with pidfile /var/run/php-fpm.pid start program = "/usr/local/etc/rc.d/php-fpm start" stop program = "/usr/local/etc/rc.d/php-fpm stop" if children > 30 then alert # Check network interface and usage. This would warn us about DDoS attacks that rely on # flooding the connection, or about an overloaded patch server. check network ix0 with interface ix0 if failed link then alert if saturation > 75% for 2 cycles then alert # Check filesystem usage - so we don't run out of disk space unexpectedly check filesystem zroot/ROOT/default with path / if space usage > 75% then alert # Check metin2 game processes, so we will get alerts on a core crash check process db with pidfile /home/metin2/db/pid.db start program = "/home/metin2/db/run.sh" stop program = "/home/metin2/db/shutdown.sh" mode passive check process auth with pidfile /home/metin2/auth/pid.auth start program = "/home/metin2/auth/run.sh" stop program = "/home/metin2/auth/shutdown.sh" mode passive check process channel1_game1 with pidfile /home/metin2/channel1/game1/pid.game start program = "/home/metin2/channel1/game1/run.sh" stop program = "/home/metin2/channel1/game1/shutdown.sh" mode passive check process channel1_game2 with pidfile /home/metin2/channel1/game2/pid.game start program = "/home/metin2/channel1/game2/run.sh" stop program = "/home/metin2/channel1/game2/shutdown.sh" mode passive check process channel2_game1 with pidfile /home/metin2/channel2/game1/pid.game start program = "/home/metin2/channel2/game1/run.sh" stop program = "/home/metin2/channel2/game1/shutdown.sh" mode passive check process channel2_game2 with pidfile /home/metin2/channel2/game2/pid.game start program = "/home/metin2/channel2/game2/run.sh" stop program = "/home/metin2/channel2/game2/shutdown.sh" mode passive Note that I add "mode passive" because I do not want monit to restart the server if it's down; I only want the alert sent to me. If you want monit to do that, just remove the "mode passive" lines (as I did for nginx and php-fpm) Also note that channel1_game1 are just names I give them so I can recognize them in the web interface, what matters here is the pid file. Other than that, there are plenty of examples in that file to get you started. Once we are happy with our settings, save and add the following lime to /etc/rc.conf monit_enable="YES" And now it's showtime: service monit start If we set everything properly, we should start getting e-mail alerts on our defined events. It may take some finetuning for you to discover which loads are out of the ordinary for your server and you should be warned about. For example, a simple web server with a 1 Gbps connection having 25% saturation is not normal, but if that web server is being used as a patch server, then you will probably average more than that. You may also use the web interface, though it's pretty basic in monit. This is all regarding monit the free monitoring tool, but for me the most interesting is integrating this system with M/Monit - which is a paid app (60$ for 5 hosts) but with a lifetime license so no monthly payments to worry about. I will get to this soon as it's a perfect solution of you have a bunch of servers to take care of and integrates with FreeBSD and other OS perfectly. Part B: M/Monit As promised, here is the second part of the tutorial concerning M/Monit. M/Monit is a centralized server which collects data from any number of monit hosts and stores it to keep statistics, make alerts more visual. It also allows for stopping and starting services if we set a "Stop" and "Start" parameter for them in monitrc, and you can even show the output of a command from the process list using the "check program" directive in monitrc and hovering over the process name in the M/Monit list. Now it's when things get pretty, with pie charts, responsive interfaces and whatnot. Take a look at this beauty: Now as I said at the beginning there's lots of pretty monitoring interfaces you can buy in the internet and M/Monit is not the prettiest but there's two things that make it stand out: 1. It works perfectly with FreeBSD, as it integrates with monit which has been a standard package in FreeBSD for many years. 2. It's not a SaaS cash cow charging you a fortune every month - you pay once and it's yours forever. So first thing you should get yourself a license here: https://mmonit.com/shop/ As you can see it's 65€ for up to 5 hosts - lifetime. Those hosts do not need to be FreeBSD, it can be any mix of systems, but I will explain here how to install it on FreeBSD because their documentation, as it happens often, kind of ignores our OS, despite it being supported. While monit should be installed in every server you want to monitor, M/Monit only needs to be installed once, in any server you want (you could even install it in your own PC). Just make sure firewall rules allow traffic between the monit and mmonit instances (monit: port 2812; mmonit: 8080). This M/Monit server should be running a database server - I will assume you have MySQL but SQLite and PostgreSQL are supported too. (credit: I got some of these instructions from a post by SirDice in the official FreeBSD forum) Once you purchased the package extract it (replace the <X.X.X> with your version) tar -C /usr/local -zxvf mmonit-<X.X.X>-freebsd-x64.tar.gz ln -s /usr/local/mmonit-<X.X.X> /usr/local/mmonit As SirDice explains "The symlink allows you to keep the old versions and switch back in case of problems. ". So whenever you want to install a new version you just need to delete the symlink and then follow these same steps, copying over your configuration to the new folder. Now edit the config: ee /usr/local/mmonit/conf/server.xml The parts we should edit: <Connector address="x.x.x.x" port="8080" processors="10" /> Change that IP for that server's public IP - this is where mmonit will listen for connections. <Engine name="mmonit" defaultHost="mmonit.mydomain.com" fileCache="10MB"> Here we could use the same IP again or, if you want to use a DNS entry instead such as mmonit.mydomain.com, place it here. This is the hostname that we will use to connect to the interface. Now create a database "mmonit" in your MySQL server and a local user like this: CREATE DATABASE mmonit; CREATE USER 'mmonit'@'localhost' IDENTIFIED BY 'mmonit'; GRANT ALL PRIVILEGES ON mmonit.* TO 'mmonit'@'localhost'; and uncomment/edit the following lines in Server.xml: <Realm url="mysql://mmonit:mmonit@localhost/mmonit" minConnections="5" maxConnections="25" reapConnections="300" /> Another line to change here is: <Host name="mmonit.mydomain.com" appBase="." > Here we should replace it once again with the hostname we defined earlier or the server's IP. Finally at the end of the file you should paste the license information you got when purchasing mmonit. Now let's add a startup script for the service on /usr/local/etc/rc.d/mmonit #!/bin/sh # PROVIDE: mmonit # REQUIRE: DAEMON # KEYWORD: shutdown # # Add the following line to /etc/rc.conf to enable M/Monit # # mmonit_enable="YES" . /etc/rc.subr name=mmonit rcvar=mmonit_enable load_rc_config "$name" : ${mmonit_enable:="NO"} command="/usr/local/mmonit/bin/mmonit" command_args="" start_precmd="mmonit_checkconfig" stop_cmd="mmonit_stop" start_cmd="mmonit_start" mmonit_checkconfig () { echo "Performing sanity check on M/Monit configuration:" eval ${command} ${mmonit_flags} -t } mmonit_start () { echo "Starting M/Monit:" eval ${command} ${mmonit_flags} start } mmonit_stop () { echo "Stopping M/Monit:" eval ${command} stop } run_rc_command "$1" Remember to chmod 777 this file after you save it, as it is supposed to be an executable. Now and before we run the service, it's time to configure our monit (not mmonit) instances that we set up in the first part to communicate with mmonit. So go back to /usr/local/etc/monitrc in each server where you installed it and uncomment & edit the following lines: set mmonit http://monit:<somepassword>@mmonit.mydomain.com:8080/collector Also in order to issue commands from MMonit to Monit, such as stopping a service remotely, we need to do the following (once again if you don't have your own domain you can replace mmonit.mydomain.com with the M/Monit server IP) set httpd port 2812 and allow 127.0.0.1 allow mmonit.mydomain.com allow monit:<somepassword> In both cases we replace mmonithost with either the IP address or the domain we set previously for mmonit, and <somepassword> with a secure password - this is used for monit and mmonit to communicate with each other, so we don't need to remember it ourselves. Now let's go back once again to the server where we just installed M/Monit and add this in /etc/rc.conf to auto start mmonit. mmonit_enable="YES" And start the service with: service mmonit start Now we should be able to browse to the IP or hostname we configured previously. http://mmonit.mydomain.com:8080/ The default user and password are admin:swordfish, you should of course change this inmediately from the web interface itself (Admin menu > Users) If everything is done properly, we will get those pretty statistics right in our browser. You can read more about mmonit in the manual: https://mmonit.com/documentation/mmonit_manual.pdf
  4. Hi everyone! There is a simple renewal make.sh for qc file: https://github.com/mertkan-k/Metin2-Renewal-Make-Quest
  5. My problem suddenly increased the use of the game section. Does anyone have an idea about this?
  6. Hi devs, I'm not a person who discovered this issue but I would like to share this with you. According to source: „On September 24, 2014, a GNU Bash vulnerability, referred to as Shellshock or the "Bash Bug", was disclosed. In short, the vulnerability allows remote attackers to execute arbitrary code given certain conditions, by passing strings of code following environment variable assignments. Because of Bash's ubiquitous status amongst Linux, BSD, and Mac OS X distributions, many computers are vulnerable to Shellshock; all unpatched Bash versions between 1.14 through 4.3 (i.e. all releases until now) are at risk.“ How to check if my machine is in a risk? All you have to do is execute this code: env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test" If your output is „Bash Test“, then you are safe and you can continue without any troubles. In oposite case you have to be worried, because your input is „Bash is vulnerable!“ and your machine is not safe. How do I become safe? You should update version of bash ASAP. You can do it easily by executing this command: pkg upgrade bash Attention: Now execute test program again and you should be safe, because it will give you correct output. Sources: https://en.wikipedia.org/wiki/Bash_(Unix_shell) https://www.digitalocean.com/community/tutorials/how-to-protect-your-server-against-the-shellshock-bash-vulnerability https://stackoverflow.com/questions/26041877/how-to-check-and-upgrade-bash-on-freebsd-related-to-the-shellshock-bug?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa
  7. Hello everyone, today I'll show you how to enable acces to root login via Putty. Yes, I know SSH accesing is better, but there is tut how to enable root login in FreeBSD 10. So first log in to your FreeBSD 10. And write this: vi /etc/ssh/sshd_config Then you should search line like this: #PermitRootLogin no Remove # and replace no to yes, like this: PermitRootLogin yes Final step is to restart your sshd /etc/rc.d/sshd restart And that's it. It's really simply and this tutorial is for real amateur in this biz. But I think it can be useful. Peace, TyWin
  8. Toxic

    [BSD]Source

    Hi people, it's possible to compile source on 64bit bsd? Because ovh has got only 64bit version of bsd.. and i can't buy a new server at the moment. Thanks a lot.
×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.