Linux-kezdő

systemctl status failed-et jelez, miután a Postgres-t pg_ctl-lel restartoltam

Fórumok

Sziasztok!

PostgreSQL-el ismerkedem, ezért egy CentOS 7.1-re repo-ból felraktam a 9.4-es verziót. (Az itteni leírás szerint: https://wiki.postgresql.org/wiki/YUM_Installation)
Minden szép és jó, csak egy érdekességre lettem figyelmes a postgres service leállításával/elindításával kapcsolatban.

A start/stop megy a pg_ctl segítségével (pg_ctl stop -m fast; pg_ctl start) illetve systemctl-el is (systemctl stop postgresql-9.4.service; systemctl start postgresql-9.4.service).

Ami érdekes a systemctl status postgresql-9.4.service kimenete, ha pg_ctl-el újra lett indítva a DB:

# systemctl status postgresql-9.4.service
postgresql-9.4.service - PostgreSQL 9.4 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-9.4.service; enabled)
Active: failed (Result: exit-code) since sze 2015-10-28 14:00:48 CET; 2s ago
Process: 3770 ExecStop=/usr/pgsql-9.4/bin/pg_ctl stop -D ${PGDATA} -s -m fast (code=exited, status=1/FAILURE)
Process: 3754 ExecStart=/usr/pgsql-9.4/bin/pg_ctl start -D ${PGDATA} -s -w -t 300 (code=exited, status=0/SUCCESS)
Process: 3749 ExecStartPre=/usr/pgsql-9.4/bin/postgresql94-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 3759 (code=exited, status=0/SUCCESS)

okt 28 14:00:37 postgresql-test systemd[1]: Starting PostgreSQL 9.4 database server...
okt 28 14:00:37 postgresql-test pg_ctl[3754]: < 2015-10-28 14:00:37.266 CET >LOG: redirecting log output to logging collector process
okt 28 14:00:37 postgresql-test pg_ctl[3754]: < 2015-10-28 14:00:37.266 CET >HINT: Future log output will appear in directory "pg_log".
okt 28 14:00:38 postgresql-test systemd[1]: Started PostgreSQL 9.4 database server.
okt 28 14:00:48 postgresql-test pg_ctl[3770]: pg_ctl: PID file "/var/lib/pgsql/9.4/data/postmaster.pid" does not exist
okt 28 14:00:48 postgresql-test pg_ctl[3770]: Is server running?
okt 28 14:00:48 postgresql-test systemd[1]: postgresql-9.4.service: control process exited, code=exited status=1
okt 28 14:00:48 postgresql-test systemd[1]: Unit postgresql-9.4.service entered failed state.

Azt értem, hogy ha a systemd-t megkerülve birizgáltam a service-t és megváltozott a PID-je, ezért failed a státusz.
De van arra valami megoldás, hogy a systemd-nél kikényszerítsem, hogy az új PID-del futó postgres-t nézze?

Ami megoldást erre találtam az az, hogy pg_ctl stop segítségével megállítom a DB-t, majd systemctl start-tal elindítom, utána active (running) státuszú, amíg a pg_ctl-el megint hozzá nem nyúlok.

0- ra gyalult fajl visszahozasa

Fórumok

Udv!

Egy veletlen elkovetett

echo > file

hiba (

echo >> file

helyett) kijavitasarol erdeklodnek. Nagyjabol nehany perce tortent. A fajl igazabol nem lenyeges, megis orulnek, ha vissza lehetne allitani. Tudtok olyan modszert, amihez nem szukseges a particio lecsatolasa? Egy mukodo szerveren van. A rendszer eleg regi, debian 6.0.2- es.

Koszi.

Piwik migrációs hiba

Fórumok

Sziasztok,

Olyan problémám lenne, hogy átvittem a PiWiK-et egyik szerverről a másikra, de valami hibát generál, de nem tudtam rájönni mi ez.

Kérdésem, hogy ez mi lehet? Hogyan lehetne életet rakni a Piwik-be?

http://s29.postimg.org/4c3kccrev/Piwik_Adminisztr_ci.png

Hiba:

LOAD DATA INFILE
Using LOAD DATA INFILE will greatly speed Piwik's archiving process up. To make it available to Piwik, try updating your PHP & MySQL software and make sure your database user has the FILE privilege.
If your Piwik server tracks high traffic websites (eg. > 100,000 pages per month), we recommend to try fix this problem.
Hiba: LOAD DATA INFILE failed... Error was:
Try #1: LOAD DATA INFILE : SQLSTATE[HY000]: General error: 13 Can't get stat of '/var/www/virtual/xxxxx.info/piwik/htdocs/tmp/assets/piwik_option-64e4311afef7e0d600bb1ab6e4318a2c.csv' (Errcode: 13)
Troubleshooting: FAQ on piwik.org

A temp-et is töröltem, létre is hozta a filekot, ezért nem is értem mi a baja :(

Köszi

Kalmi

Rsync kérdés

Fórumok

Sziasztok!

Mentés céljából rsync-elnék egy komplett maildir könyvtárat egy másik gépre.
Kezdetnek összetaroltam a 28G adatot és átvittem a másik gépre.
Ott annyit követtem el, hogy a /data/vmail könyvtár csoportját megváltoztattam, mert ezen a gépen nincs olyan csoport.
Pár hét múlva gondoltam rsync-elek egyet, hogy up to date-ek legyenek a levelek, de a változások helyett az egész 28 gigát elkezdte újra áthúzni.
Lehetséges, hogy a csoportjog változás miatt húz át újra mindent?

Így csináltam:
rsync -vaK --delete victorpictor@host:/data/vmail/ /data/vmail/

Köszönöm,
Victorpictor

GlusterFS geo-replication tapasztalatok

Fórumok

Sziasztok!

Érdekelnének a tapasztalataitok GlusterFS geo-replication-el kapcsolatosan.
2 szerver között szeretnék egy replicát csinálni, 100M interneten keresztül (Egyik szerver a saját szervertermünkben van, és egy GTS-ben lévő szerverre szeretnék replicálni)
Azt olvastam a sima GlusterFS erre nem megfelelő, inkább a geo-replication.

Köszi: Andris

[Megoldva] Egyetlen file törölhetetlenné tétele hogyan?

Fórumok

Van egy alkönyvtár, abban több file. Ezek közül egyet törölhetetlenné kellene tenni. A filerendszer ext4.

Az alkönyvtár többi file-ját kell tudni törölni, tehát a tartalmazó alkönyvtárra kell írási jog. Minden file-t kell tudni módosítani, így az immutable flag nem jó.

Van erre megoldás? Sima user jogú alkalmazásnak kell tudnia nem törölni az érintett egy file-t.

Update

Köszönöm mindenkinek a segítséget, együtt gondolkodást. A bind mount önmagára nagyszerű ötlet, elrakom az emlékezetembe. Végül a Claws-Mail kliens használata mellett döntöttem, ebben a jogok állíthatók.

Thunderbird Trash 0660 jogot hogyan?

Fórumok

Gondom az alábbi. Két különböző felhasználói profil alól szeretném ugyanazt a mailboxot elérni és használni thunderbird-ben. Van user1, itt a profil eredetileg. Van user2, itt a profil másolata néhány dolog módosításával, az érintett mailbox alkönyvtára viszont egy symlink user1-ben található mailbox alkönyvtárára.

Természetesen user1 és user2 egy közös csoportban vannak, az umask pedig 0002. Mind user1-nek, mind pedig user2-nek a default csoportja ezen közös, mondjuk csop nevű csoport.

A probléma az, hogy a thunderbird a Trash file-t user1:csop 0600-ra állítja, így természetesen user2 nem tudja írni, éppen ezért user2 alól nem tudok levelet törölni.

Próbálkoztam azzal, hogy a Trash legyen root:csop 0660 jogú, de hogy, s hogy nem, azt vettem észre, amikor nem sikerült a levél törlése, hogy már megint user1:csop 0600 a Trash joga.

Nem igazán értem, egy chmod és chown parancsokkal root:csop jogait például user1 által nem tudom megváltoztatni, mert nincs rá jogom.

A thunderbird sima felhasználóként hogyan tudta saját tulajdonba venni a Trash file-t, vagy mi történhetett? Továbbá hogyan tudom elérni, hogy 0660 maradjon a Trash joga, ne pedig 0600, ahogyan ezen a thunderbird izmozik?

apc.so és mysqlnd.so file-ok pótlása

Fórumok

Sziasztok,

a következő a problémám. Egy I-MSCP hostingon, egy NGNIX PHP-FPM fut.

Rendszer:
Distributor ID: Debian
Description: Debian GNU/Linux 8.2 (jessie)
Release: 8.2
Codename: jessie

Az apc-t a "#pecl install apc" tettem fel a végén kaptam hibát:
---
...
/tmp/pear/temp/APC/apc_cache.c: In function '_apc_cache_user_update':
/tmp/pear/temp/APC/apc_cache.c:818:63: error: 'IS_CONSTANT_INDEX' undeclared (first use in this function)
switch(Z_TYPE_P((*slot)->value->data.user.val) & ~IS_CONSTANT_INDEX) {
^
/tmp/pear/temp/APC/apc_cache.c:818:63: note: each undeclared identifier is reported only once for each function it appears in
/tmp/pear/temp/APC/apc_cache.c:820:22: error: 'IS_CONSTANT_ARRAY' undeclared (first use in this function)
case IS_CONSTANT_ARRAY:
^
Makefile:186: recipe for target 'apc_cache.lo' failed
make: *** [apc_cache.lo] Error 1
ERROR: `make' failed
---
Viszont elvileg fut, de hibával.

# php -m
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20131226/mysqlnd.so' - /usr/lib/php5/20131226/mysqlnd.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20131226/apc.so' - /usr/lib/php5/20131226/apc.so: cannot open shared object file: No such file or directory in Unknown on line 0
[PHP Modules]
apc
apcu
bcmath
bz2
calendar
Core
ctype
curl
date
dba
dom
ereg
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
imap
intl
json
libxml
mbstring
mcrypt
memcached
mhash
mysql
mysqli
openssl
pcntl
pcre
PDO
pdo_mysql
Phar
posix
Reflection
session
shmop
SimpleXML
soap
sockets
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xml
xmlreader
xmlwriter
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache
---
Ellenőriztem a jelzett helyet:
-rw-r--r-- 1 root root 102K okt 23 2014 apcu.so
-rw-r--r-- 1 root root 88K szept 7 15:49 curl.so
-rw-r--r-- 1 root root 112K szept 7 15:49 gd.so
-rw-r--r-- 1 root root 178K okt 4 16:07 gnupg.so
-rw-r--r-- 1 root root 108K szept 7 15:49 imap.so
-rw-r--r-- 1 root root 406K szept 7 15:49 intl.so
-rw-r--r-- 1 root root 39K aug 1 2014 json.so
-rw-r--r-- 1 root root 47K szept 7 15:49 mcrypt.so
-rw-r--r-- 1 root root 106K okt 25 2014 memcached.so
-rw-r--r-- 1 root root 152K szept 7 15:49 mysqli.so
-rw-r--r-- 1 root root 60K szept 7 15:49 mysql.so
-rw-r--r-- 1 root root 157K szept 7 15:49 opcache.so
-rw-r--r-- 1 root root 36K szept 7 15:49 pdo_mysql.so
-rw-r--r-- 1 root root 116K szept 7 15:49 pdo.so
-rw-r--r-- 1 root root 55K okt 4 15:54 uploadprogress.so

Itt valóban nincs meg a két file: mysqlnd.so;apc.so
Viszont az APC "elvileg hibátlanul megy és a szerver is.

http://www.eupalyazat.info/php.php
http://www.eupalyazat.info/apc/apc.php

#cat /etc/php5/mods-available/apc.ini

extension=apc.so
apc.enabled=1
apc.shm_segments=1
apc.shm_size=1000M
apc.ttl=86400
apc.write_lock = 1
apc.slam_defense = 0

apc.enable_cli=1
apc.stat=1
apc.max_file_size=1M
apc.mmap_file_mask=/var/tmp/apc/apc.XXXXXX
apc.num_files_hint=15360
apc.user_entries_hint=15360
apc.optimization=0
apc.localcache=1
apc.localcache.size=256
apc.lazy_functions=1
apc.lazy_classes=1
apc.gc_ttl=3600

Kérdésem, hogy hol van a két file, hogyan tud működni, ha nincsenek meg, illetve hogyan lehet kijavítani a hibát?

Köszi előre is!

Kalmi

postfix + ldap + virtualusers + dovecot + mailman

Fórumok

Hali,

van egy banatom a fenti konstellacioval, megpedig, hogy nem mukodik.

Az az elmelet, hogy beesik a level, a postfix megnezi, hogy van-e ilyen helyi felhasznalo, vagy a virtualis userleiro tablaban van-e deifnialva, ha van es mondjuk at van kergetve egy lokalis felhasznaloba, akkor megnezi az alias tablat, majd az alapjan kitalalja a frankot.

Namarmost nekem az egesz rendszer egy gepen futna, legyen ez a egygep.example.com, viszont szeretnem a leveleket meg a levlistakat a example.com-mal hasznalni.
Namarmost az example.com benne van a virtual domainek kozott. Ha az egygep.example.com-ra csinalok levlistat, akkor az mukodni latszik.
HA definialok ra ransport_maps = hash:/etc/postfix/transport -ot, akkor bajsag van, mert ha mailman van odairva, akkor nem tudja kiszedni az ldap-bol a felhasznalokat, es eldobalja a leveleket, hogy nicns ilyen felhasznalo. Ha nem mailman van, akkor meg nem tudja kitalalni a listatagokat, es lerakja helyi felhasznalokent a levelet mondjuk a test-l@example.com leveleket a test-l felhasznalonak.

Megitelesem szerint ezek a sorok vonatkoznak a mailman-re a postfix configban:

# transport_maps = hash:/etc/postfix/transport
alias_maps = hash:/etc/postfix/aliases, hash:/var/lib/mailman/data/aliases
alias_database = hash:/etc/postfix/aliases, hash:/var/lib/mailman/data/aliases
dovecot_destination_recipient_limit = 1
virtual_mailbox_base=/var/vmail
virtual_mailbox_domains=hash:/etc/postfix/virtual_mailbox_domains
virtual_mailbox_maps=hash:/etc/postfix/virtual_mailbox_maps, ldap:/etc/postfix/ldap_virtual_mailbox_maps.cf
virtual_alias_maps=hash:/etc/postfix/virtual_alias_maps, ldap:/etc/postfix/ldap_virtual_alias_maps.cf, hash:/var/lib/mailman/data/virtual-mailman
virtual_transport=dovecot


mailman unix - n n - - pipe
flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
${nexthop} ${user}

Kicsit osszekavarodtam, hogy akkor most kell a mailmannek ez:


MTA='Postfix'

vagy sem? De tokmindegy mert nem latok mukodesbeli kulonbseget. Ha nem adom meg a transport map-ben, hogy mailmen, akkor a dovecot lerakja:


relay=dovecot, delay=0.04, delays=0.01/0/0/0.03, dsn=2.0.0, status=sent (delivered via dovecot service)

Hol rontom el? Egyertelmu, hogy a postfix-nel hianyzik meg valami, csak nem jovok ra, hogy mi?