🥇ஜிம்ப்ரா OSE பதிவுகளுடன் எவ்வாறு வேலை செய்வது

நிகழும் அனைத்து நிகழ்வுகளையும் பதிவு செய்வது எந்த நிறுவன அமைப்பின் மிக முக்கியமான செயல்பாடுகளில் ஒன்றாகும். வளர்ந்து வரும் சிக்கல்களைத் தீர்ப்பதற்கும், தகவல் அமைப்புகளின் செயல்பாட்டைத் தணிக்கை செய்வதற்கும், தகவல் பாதுகாப்பு சம்பவங்களை விசாரிக்கவும் பதிவுகள் உங்களை அனுமதிக்கின்றன. ஜிம்ப்ரா ஓஎஸ்இ அதன் செயல்பாட்டின் விரிவான பதிவுகளையும் வைத்திருக்கிறது. சர்வர் செயல்திறன் முதல் பயனர்கள் மின்னஞ்சல்களை அனுப்புவது மற்றும் பெறுவது வரை அனைத்து தரவையும் உள்ளடக்கியது. இருப்பினும், ஜிம்ப்ரா OSE ஆல் உருவாக்கப்பட்ட பதிவுகளைப் படிப்பது மிகவும் அற்பமான செயல் அல்ல. இந்த கட்டுரையில், ஒரு குறிப்பிட்ட உதாரணத்தைப் பயன்படுத்தி, ஜிம்ப்ரா OSE பதிவுகளை எவ்வாறு படிப்பது என்பதையும், அவற்றை எவ்வாறு மையப்படுத்துவது என்பதையும் நாங்கள் உங்களுக்குக் கூறுவோம்.

ஜிம்ப்ரா OSE அனைத்து உள்ளூர் பதிவுகளையும் /opt/zimbra/log கோப்புறையில் சேமிக்கிறது, மேலும் பதிவுகளை /var/log/zimbra.log கோப்பிலும் காணலாம். இதில் முக்கியமானது mailbox.log. இது அஞ்சல் சேவையகத்தில் நிகழும் அனைத்து செயல்களையும் பதிவு செய்கிறது. மின்னஞ்சல்களின் பரிமாற்றம், பயனர் அங்கீகாரத் தரவு, தோல்வியுற்ற உள்நுழைவு முயற்சிகள் மற்றும் பிறவற்றை உள்ளடக்கியது. mailbox.log இல் உள்ள உள்ளீடுகள் என்பது நிகழ்வு நிகழ்ந்த நேரம், நிகழ்வின் நிலை, நிகழ்வு நிகழ்ந்த நூல் எண், பயனர் பெயர் மற்றும் IP முகவரி, அத்துடன் நிகழ்வின் உரை விளக்கம் ஆகியவற்றைக் கொண்ட உரைச் சரம் ஆகும். .

பதிவு நிலை சர்வரின் செயல்பாட்டில் நிகழ்வின் செல்வாக்கின் அளவைக் குறிக்கிறது. இயல்பாக 4 நிகழ்வு நிலைகள் உள்ளன: தகவல், எச்சரிக்கை, பிழை மற்றும் அபாயகரமானது. தீவிரத்தன்மையை அதிகரிக்கும் வரிசையில் அனைத்து நிலைகளையும் பார்ப்போம்.

தகவல் - இந்த மட்டத்தில் நிகழ்வுகள் பொதுவாக Zimbra OSE இன் முன்னேற்றத்தைப் பற்றி தெரிவிக்கும் நோக்கத்துடன் இருக்கும். இந்த நிலையில் உள்ள செய்திகளில் அஞ்சல் பெட்டியை உருவாக்குதல் அல்லது நீக்குதல் பற்றிய அறிக்கைகள் மற்றும் பல உள்ளன.
எச்சரிக்கை - இந்த நிலை நிகழ்வுகள் ஆபத்தான சூழ்நிலைகளைப் பற்றி தெரிவிக்கின்றன, ஆனால் சேவையகத்தின் செயல்பாட்டை பாதிக்காது. எடுத்துக்காட்டாக, WARN நிலை தோல்வியடைந்த பயனர் உள்நுழைவு முயற்சியைப் பற்றிய செய்தியைக் குறிக்கிறது.
பிழை - பதிவில் உள்ள இந்த நிகழ்வு நிலை, உள்ளூர் இயல்புடைய மற்றும் சேவையகத்தின் செயல்பாட்டில் தலையிடாத பிழையின் நிகழ்வைப் பற்றி தெரிவிக்கிறது. இந்த நிலை ஒரு தனிப்பட்ட பயனரின் குறியீட்டுத் தரவு சிதைந்த பிழையைக் கொடியிடலாம்.
FATAL - இந்த நிலை பிழைகளைக் குறிக்கிறது, இதன் காரணமாக சர்வர் தொடர்ந்து செயல்பட முடியாது. எடுத்துக்காட்டாக, DBMS உடன் இணைக்க இயலாமையைக் குறிக்கும் பதிவுக்கான FATAL நிலை இருக்கும்.

அஞ்சல் சேவையக பதிவு கோப்பு ஒவ்வொரு நாளும் புதுப்பிக்கப்படும். கோப்பின் சமீபத்திய பதிப்பில் எப்போதும் Mailbox.log என்ற பெயர் இருக்கும், அதே நேரத்தில் ஒரு குறிப்பிட்ட தேதிக்கான பதிவுகள் பெயரில் தேதியைக் கொண்டிருக்கும் மற்றும் காப்பகத்தில் இருக்கும். உதாரணமாக mailbox.log.2020-09-29.tar.gz. இது செயல்பாட்டுப் பதிவுகளை காப்புப் பிரதி எடுப்பதையும் பதிவுகள் மூலம் தேடுவதையும் மிகவும் எளிதாக்குகிறது.

கணினி நிர்வாகியின் வசதிக்காக, /opt/zimbra/log/ கோப்புறையில் மற்ற பதிவுகள் உள்ளன. குறிப்பிட்ட ஜிம்ப்ரா OSE உறுப்புகளுடன் தொடர்புடைய உள்ளீடுகளை மட்டுமே அவை உள்ளடக்கும். எடுத்துக்காட்டாக, audit.log பயனர் அங்கீகாரத்தைப் பற்றிய பதிவுகளை மட்டுமே கொண்டுள்ளது, clamd.log வைரஸ் தடுப்பு செயல்பாட்டைப் பற்றிய தரவைக் கொண்டுள்ளது மற்றும் பல. மூலம், ஊடுருவும் நபர்களிடமிருந்து ஜிம்ப்ரா OSE சேவையகத்தைப் பாதுகாப்பதற்கான ஒரு சிறந்த முறை Fail2Ban ஐப் பயன்படுத்தி சர்வர் பாதுகாப்பு, இது audit.log அடிப்படையில் மட்டுமே செயல்படுகிறது. கட்டளையை இயக்க ஒரு கிரான் பணியைச் சேர்ப்பதும் ஒரு நல்ல நடைமுறையாகும் grep -ir "தவறான கடவுச்சொல்" /opt/zimbra/log/audit.logதினசரி உள்நுழைவு தோல்வி தகவலைப் பெற.

இரண்டு முறை தவறாக உள்ளிடப்பட்ட கடவுச்சொல்லையும் வெற்றிகரமான உள்நுழைவு முயற்சியையும் audit.log எவ்வாறு காட்டுகிறது என்பதற்கான எடுத்துக்காட்டு.

ஜிம்ப்ரா OSE இல் உள்ள பதிவுகள் பல்வேறு முக்கியமான தோல்விகளுக்கான காரணங்களைக் கண்டறிவதில் மிகவும் பயனுள்ளதாக இருக்கும். ஒரு முக்கியமான பிழை ஏற்படும் தருணத்தில், நிர்வாகிக்கு பொதுவாக பதிவுகளைப் படிக்க நேரமில்லை. சேவையகத்தை விரைவில் மீட்டெடுக்க வேண்டியது அவசியம். இருப்பினும், பின்னர், சேவையகம் காப்புப் பிரதி எடுக்கப்பட்டு, நிறைய பதிவுகளை உருவாக்கும் போது, ஒரு பெரிய கோப்பில் தேவையான உள்ளீட்டைக் கண்டறிவது கடினமாக இருக்கும். பிழை பதிவை விரைவாகக் கண்டறிய, சேவையகம் மறுதொடக்கம் செய்யப்பட்ட நேரத்தை அறிந்து, இந்த நேரத்திலிருந்து பதிவுகளில் உள்ளீட்டைக் கண்டறிவது போதுமானது. முந்தைய பதிவு ஏற்பட்ட பிழையின் பதிவாக இருக்கும். FATAL என்ற முக்கிய சொல்லைத் தேடுவதன் மூலமும் பிழைச் செய்தியைக் கண்டறியலாம்.

ஜிம்ப்ரா OSE பதிவுகள் முக்கியமான தோல்விகளை அடையாளம் காண உங்களை அனுமதிக்கின்றன. எடுத்துக்காட்டாக, ஹேண்ட்லர் விதிவிலக்குகளைக் கண்டறிய, ஹேண்ட்லர் விதிவிலக்கைத் தேடலாம். பெரும்பாலும், கையாளுபவர்களால் உருவாக்கப்படும் பிழைகள், விதிவிலக்கிற்கு என்ன காரணம் என்பதை விளக்கும் ஸ்டாக் ட்ரேஸுடன் இருக்கும். அஞ்சல் விநியோகத்தில் பிழைகள் ஏற்பட்டால், உங்கள் தேடலை LmtpServer முக்கிய சொல்லுடன் தொடங்க வேண்டும், மேலும் POP அல்லது IMAP நெறிமுறைகள் தொடர்பான பிழைகளைத் தேட, நீங்கள் ImapServer மற்றும் Pop3Server முக்கிய வார்த்தைகளைப் பயன்படுத்தலாம்.

தகவல் பாதுகாப்பு சம்பவங்களை விசாரிக்கும் போது பதிவுகள் உதவலாம். ஒரு குறிப்பிட்ட உதாரணத்தைப் பார்ப்போம். செப்டம்பர் 20 அன்று, ஊழியர்களில் ஒருவர் வாடிக்கையாளர் ஒருவருக்கு வைரஸ் தொற்று கடிதத்தை அனுப்பினார். இதன் விளைவாக, கிளையண்டின் கணினியில் உள்ள தரவு குறியாக்கம் செய்யப்பட்டது. இருப்பினும், அவர் எதையும் அனுப்பவில்லை என்று ஊழியர் சத்தியம் செய்கிறார். சம்பவம் தொடர்பான விசாரணையின் ஒரு பகுதியாக, நிறுவனப் பாதுகாப்புச் சேவையானது கணினி நிர்வாகியிடம் இருந்து செப்டம்பர் 20 ஆம் தேதிக்கான அஞ்சல் சேவையகப் பதிவுகளை விசாரிக்கும் பயனருடன் தொடர்புடையதாகக் கோருகிறது. நேர முத்திரைக்கு நன்றி, கணினி நிர்வாகி தேவையான பதிவு கோப்பைக் கண்டுபிடித்து, தேவையான தகவல்களைப் பிரித்தெடுத்து பாதுகாப்பு நிபுணர்களுக்கு மாற்றுகிறார். அவர்கள், இதைப் பார்த்து, இந்த கடிதம் அனுப்பப்பட்ட ஐபி முகவரி பயனரின் கணினியின் ஐபி முகவரிக்கு ஒத்திருப்பதைக் கண்டறியவும். கடிதம் அனுப்பப்பட்டபோது ஊழியர் தனது பணியிடத்தில் இருந்ததை சிசிடிவி காட்சிகள் உறுதிப்படுத்தின. தகவல் பாதுகாப்பு விதிகளை மீறியதாக குற்றம் சாட்டி அவரை பணிநீக்கம் செய்ய இந்தத் தரவு போதுமானதாக இருந்தது.

Mailbox.log உள்நுழைவிலிருந்து கணக்குகளில் ஒன்றைப் பற்றிய பதிவுகளை ஒரு தனி கோப்பில் பிரித்தெடுப்பதற்கான எடுத்துக்காட்டு

பல சேவையக உள்கட்டமைப்புக்கு வரும்போது எல்லாம் மிகவும் சிக்கலானதாகிறது. பதிவுகள் உள்நாட்டில் சேகரிக்கப்படுவதால், பல சேவையக உள்கட்டமைப்பில் அவர்களுடன் பணிபுரிவது மிகவும் சிரமமாக உள்ளது, எனவே பதிவுகளின் சேகரிப்பை மையப்படுத்த வேண்டிய அவசியம் உள்ளது. பதிவுகளை சேகரிக்க ஹோஸ்ட்டை அமைப்பதன் மூலம் இதைச் செய்யலாம். உள்கட்டமைப்பிற்கு பிரத்யேக ஹோஸ்ட்டை சேர்க்க வேண்டிய அவசியமில்லை. எந்த அஞ்சல் சேவையகமும் பதிவுகளை சேகரிக்கும் முனையாக செயல்பட முடியும். எங்கள் விஷயத்தில், இது Mailstore01 முனையாக இருக்கும்.

இந்த சேவையகத்தில் நாம் பின்வரும் கட்டளைகளை உள்ளிட வேண்டும்:

sudo su – zimbra 
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -v

/etc/sysconfig/rsyslog கோப்பைத் திருத்தி, SYSLOGD_OPTIONS=”-r -c 2″ ஐ அமைக்கவும்

பின்வரும் வரிகளை /etc/rsyslog.conf ஐத் திருத்தவும் மற்றும் கருத்து நீக்கவும்:
$ModLoad imudp
$UDPServerRun 514

பின்வரும் கட்டளைகளை உள்ளிடவும்:

sudo /etc/init.d/rsyslog stop
sudo /etc/init.d/rsyslog start
sudo su – zimbra
zmcontrol start
exit
sudo /opt/zimbra/libexec/zmloggerinit
sudo /opt/zimbra/bin/zmsshkeygen
sudo /opt/zimbra/bin/zmupdateauthkeys

zmprov gacf | கட்டளையைப் பயன்படுத்தி அனைத்தும் செயல்படுகின்றனவா என்பதை நீங்கள் சரிபார்க்கலாம் grep zimbraLogHostname. கட்டளையை இயக்கிய பிறகு, பதிவுகளை சேகரிக்கும் ஹோஸ்டின் பெயர் காட்டப்பட வேண்டும். அதை மாற்ற, நீங்கள் கட்டளையை உள்ளிட வேண்டும் zmprov mcf zimbraLogHostname mailstore01.company.ru.

மற்ற அனைத்து உள்கட்டமைப்பு சேவையகங்களிலும் (LDAP, MTA மற்றும் பிற அஞ்சல் கடைகள்), பதிவுகள் அனுப்பப்படும் ஹோஸ்ட்டின் பெயரைக் காண zmprov gacf |grep zimbraLogHostname கட்டளையை இயக்கவும். அதை மாற்ற, நீங்கள் கட்டளையை உள்ளிடலாம் zmprov mcf zimbraLogHostname mailstore01.company.ru

ஒவ்வொரு சேவையகத்திலும் பின்வரும் கட்டளைகளை உள்ளிட வேண்டும்:

sudo su - zimbra
/opt/zimbra/bin/zmsshkeygen
/opt/zimbra/bin/zmupdateauthkeys
exit
sudo /opt/zimbra/libexec/zmsyslogsetup
sudo service rsyslog restart
sudo su - zimbra
zmcontrol restart

இதற்குப் பிறகு, அனைத்து பதிவுகளும் நீங்கள் குறிப்பிட்ட சேவையகத்தில் பதிவு செய்யப்படும், அங்கு அவை வசதியாகப் பார்க்கப்படும். மேலும், ஜிம்ப்ரா OSE நிர்வாகி கன்சோலில், சேவையகங்களின் நிலை பற்றிய தகவலுடன் திரையில், இயங்கும் லாகர் சேவை mailstore01 சேவையகத்திற்கு மட்டுமே காட்டப்படும்.

ஒரு நிர்வாகிக்கு மற்றொரு தலைவலி ஒரு குறிப்பிட்ட மின்னஞ்சலைக் கண்காணிப்பது. ஜிம்ப்ரா OSE இல் உள்ள மின்னஞ்சல்கள் ஒரே நேரத்தில் பல்வேறு நிகழ்வுகளைக் கடந்து செல்வதால்: வைரஸ் தடுப்பு, ஆன்டிஸ்பேம் மற்றும் பலவற்றின் மூலம் ஸ்கேன் செய்தல், ஏற்கப்படுவதற்கு அல்லது அனுப்பப்படுவதற்கு முன், நிர்வாகிக்கு, மின்னஞ்சல் வரவில்லை என்றால், எந்த நிலையில் உள்ளது என்பதைக் கண்டுபிடிப்பது மிகவும் சிக்கலாக இருக்கும். அது தொலைந்தது .

இந்த சிக்கலை தீர்க்க, நீங்கள் ஒரு சிறப்பு ஸ்கிரிப்டைப் பயன்படுத்தலாம், இது தகவல் பாதுகாப்பு நிபுணர் விக்டர் டுகோவ்னியால் உருவாக்கப்பட்டது மற்றும் போஸ்ட்ஃபிக்ஸ் டெவலப்பர்களால் பயன்படுத்த பரிந்துரைக்கப்படுகிறது. இந்த ஸ்கிரிப்ட் ஒரு குறிப்பிட்ட செயல்முறைக்கான பதிவுகளிலிருந்து உள்ளீடுகளை ஒருங்கிணைக்கிறது, இதன் காரணமாக, அதன் அடையாளங்காட்டியின் அடிப்படையில் ஒரு குறிப்பிட்ட கடிதத்தை அனுப்புவதுடன் தொடர்புடைய அனைத்து உள்ளீடுகளையும் விரைவாகக் காண்பிக்க உங்களை அனுமதிக்கிறது. 8.7 முதல் ஜிம்ப்ரா OSE இன் அனைத்து பதிப்புகளிலும் அதன் வேலை சோதிக்கப்பட்டது. ஸ்கிரிப்ட்டின் உரை இதோ.

#! /usr/bin/perl

use strict;
use warnings;

# Postfix delivery agents
my @agents = qw(discard error lmtp local pipe smtp virtual);

my $instre = qr{(?x)
	A			# Absolute line start
	(?:S+ s+){3} 		# Timestamp, adjust for other time formats
	S+ s+ 		# Hostname
	(postfix(?:-[^/s]+)?)	# Capture instance name stopping before first '/'
	(?:/S+)*		# Optional non-captured '/'-delimited qualifiers
	/			# Final '/' before the daemon program name
	};

my $cmdpidre = qr{(?x)
	G			# Continue from previous match
	(S+)[(d+)]:s+	# command[pid]:
};

my %smtpd;
my %smtp;
my %transaction;
my $i = 0;
my %seqno;

my %isagent = map { ($_, 1) } @agents;

while (<>) {
	next unless m{$instre}ogc; my $inst = $1;
	next unless m{$cmdpidre}ogc; my $command = $1; my $pid = $2;

	if ($command eq "smtpd") {
		if (m{Gconnect from }gc) {
			# Start new log
			$smtpd{$pid}->{"log"} = $_; next;
		}

		$smtpd{$pid}->{"log"} .= $_;

		if (m{G(w+): client=}gc) {
			# Fresh transaction 
			my $qid = "$inst/$1";
			$smtpd{$pid}->{"qid"} = $qid;
			$transaction{$qid} = $smtpd{$pid}->{"log"};
			$seqno{$qid} = ++$i;
			next;
		}

		my $qid = $smtpd{$pid}->{"qid"};
		$transaction{$qid} .= $_
			if (defined($qid) && exists $transaction{$qid});
		delete $smtpd{$pid} if (m{Gdisconnect from}gc);
		next;
	}

	if ($command eq "pickup") {
		if (m{G(w+): uid=}gc) {
			my $qid = "$inst/$1";
			$transaction{$qid} = $_;
			$seqno{$qid} = ++$i;
		}
		next;
	}

	# bounce(8) logs transaction start after cleanup(8) already logged
	# the message-id, so the cleanup log entry may be first
	#
	if ($command eq "cleanup") {
		next unless (m{G(w+): }gc);
		my $qid = "$inst/$1";
		$transaction{$qid} .= $_;
		$seqno{$qid} = ++$i if (! exists $seqno{$qid});
		next;
	}

	if ($command eq "qmgr") {
		next unless (m{G(w+): }gc);
		my $qid = "$inst/$1";
		if (defined($transaction{$qid})) {
			$transaction{$qid} .= $_;
			if (m{Gremoved$}gc) {
				print delete $transaction{$qid}, "n";
			}
		}
		next;
	}

	# Save pre-delivery messages for smtp(8) and lmtp(8)
	#
	if ($command eq "smtp" || $command eq "lmtp") {
		$smtp{$pid} .= $_;

		if (m{G(w+): to=}gc) {
			my $qid = "$inst/$1";
			if (defined($transaction{$qid})) {
				$transaction{$qid} .= $smtp{$pid};
			}
			delete $smtp{$pid};
		}
		next;
	}

	if ($command eq "bounce") {
		if (m{G(w+): .*? notification: (w+)$}gc) {
			my $qid = "$inst/$1";
			my $newid = "$inst/$2";
			if (defined($transaction{$qid})) {
				$transaction{$qid} .= $_;
			}
			$transaction{$newid} =
				$_ . $transaction{$newid};
			$seqno{$newid} = ++$i if (! exists $seqno{$newid});
		}
		next;
	}

	if ($isagent{$command}) {
		if (m{G(w+): to=}gc) {
			my $qid = "$inst/$1";
			if (defined($transaction{$qid})) {
				$transaction{$qid} .= $_;
			}
		}
		next;
	}
}

# Dump logs of incomplete transactions.
foreach my $qid (sort {$seqno{$a} <=> $seqno{$b}} keys %transaction) {
    print $transaction{$qid}, "n";
}

ஸ்கிரிப்ட் பெர்லில் எழுதப்பட்டுள்ளது, அதை இயக்க நீங்கள் அதை ஒரு கோப்பில் சேமிக்க வேண்டும் collate.pl, அதை இயக்கக்கூடியதாக மாற்றவும், பின்னர் பதிவு கோப்பைக் குறிப்பிடும் கோப்பை இயக்கவும் மற்றும் நீங்கள் தேடும் கடிதத்தின் அடையாளத் தகவலைப் பிரித்தெடுக்க pgrep ஐப் பயன்படுத்தவும். collate.pl /var/log/zimbra.log | pgrep'[மின்னஞ்சல் பாதுகாக்கப்பட்டது]>’. இதன் விளைவாக, சர்வரில் உள்ள கடிதத்தின் இயக்கம் பற்றிய தகவல்களைக் கொண்ட வரிகளின் தொடர்ச்சியான வெளியீடு இருக்கும்.

# collate.pl /var/log/zimbra.log | pgrep '<[email protected]>'
Oct 13 10:17:00 mail postfix/pickup[4089]: 4FF14284F45: uid=1034 from=********
Oct 13 10:17:00 mail postfix/cleanup[26776]: 4FF14284F45: message-id=*******
Oct 13 10:17:00 mail postfix/qmgr[9946]: 4FF14284F45: from=********, size=1387, nrcpt=1 (queue active)
Oct 13 10:17:00 mail postfix/smtp[7516]: Anonymous TLS connection established to mail.*******[168.*.*.4]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Oct 13 10:17:00 mail postfix/smtp[7516]: 4FF14284F45: to=*********, relay=mail.*******[168.*.*.4]:25, delay=0.25, delays=0.02/0.02/0.16/0.06, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 878833424CF)
Oct 13 10:17:00 mail postfix/qmgr[9946]: 4FF14284F45: removed
Oct 13 10:17:07 mail postfix/smtpd[21777]: connect from zimbra.******[168.*.*.4]
Oct 13 10:17:07 mail postfix/smtpd[21777]: Anonymous TLS connection established from zimbra.******[168.*.*.4]: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Oct 13 10:17:08 mail postfix/smtpd[21777]: 0CB69282F4E: client=zimbra.******[168.*.*.4]
Oct 13 10:17:08 mail postfix/cleanup[26776]: 0CB69282F4E: message-id=zimbra.******
Oct 13 10:17:08 mail postfix/qmgr[9946]: 0CB69282F4E: from=zimbra.******, size=3606, nrcpt=1 (queue active)
Oct 13 10:17:08 mail postfix/virtual[5291]: 0CB69282F4E: to=zimbra.******, orig_to=zimbra.******, relay=virtual, delay=0.03, delays=0.02/0/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)
Oct 13 10:17:08 mail postfix/qmgr[9946]: 0CB69282F4E: removed

Zextras Suite தொடர்பான அனைத்து கேள்விகளுக்கும், நீங்கள் Zextras Ekaterina Triandafilidi இன் பிரதிநிதியை மின்னஞ்சல் மூலம் தொடர்பு கொள்ளலாம் [மின்னஞ்சல் பாதுகாக்கப்பட்டது]

ஆதாரம்: www.habr.com