Web, mail, IRC, IM, hálózatok

Sziasztok!

Két különböző Operációs rendszerre szeretnék kérni tanácsot és megoldási javaslatokat.

3-4 karbantartási helyemen levelezéssel kapcsolatos problémák lettek. A felhasználók szemszögéből és az enyémből is. Elsősorban a megnövekedett levelezés miatt .pst fájlok illetve a Thunderbird profilok elkezdtek "hízni". Az én problémám, hogy ezeknek a biztonsági mentését meg kellene oldanom. A felhasználók pedig szeretnék távolról elérni a levelezést, ahol minden levelet (elküldött levelek, stb..) látnak. Az IMAP lehet megoldás, de az egyik cégnél az email címekhez tartozó tárhelyet 1Gb-ra tudnák megnövelni egyenként (csak az egyik címhez tartozó .pst 3Gb).

Minden cégnél van egy szerver a belső hálózaton adattárolás vagy hálózatos könyvelési programok miatt, az egyik Linux (Ubuntu) a másik Windows.

Arra gondoltam, hogy csinálnék egy másodlagos levelező szervert, amely a szolgáltató POP3 szerveréről letöltené a leveleket és a belső hálózatot IMAP-pal kiszolgálná és esetleg távolról elérni egy jól működő webes felületen.

Ezzel megoldanám, hogy nem a munkaállomásokon tárolódna a levelezés illetve a felhasználók is elérik akár otthonról is a leveleiket.

Kérdésem, hogy milyen programokkal lehetne ezt megoldani?

Elsősorban ingyenes megoldások érdekelnek, de a fizetős szoftverek is szóbajöhetnek. Egy másik karbantartási helyemen használunk MailEnable-t, ami nagyon jól működik. Az ingyenes változata csak POP3-t támogatja.

Előre is köszönöm válaszaitokat

Hello,

Eventbrite alternatívákat keresek. Ha lehet tudjon magyarul.
Egy koncerthez szeretnénk online regisztrációs lehetőséget adni.

TIA,

s

Van egy HP Helionban működő rendszerem, amelyet napokon belül a Google cloudjába kell migrálnom. Eddig a kimenő levelezést egy másik saját cégem szerverén keresztül oldottam meg, de auditálási okokból ez már nem fog menni, és ha lehet, nem üzemelnék be egy külön fizikai mailszervert.
A Google – mint ahogy mások is – a SendGridet ajánlja kimenő levelezésre.
Nem küldök hírlevelet, reklámot stb., csak és kizárólag az ügyfeleknek szóló visszaigazolásokat.
Van olyan dolog, ami az ellen szól, hogy ebből a célból a SendGridet használjam? Én szívesen megúsznám a plusz egy fizikai szervert: plusz egy gond…

Sziasztok,

Más is tapasztalta, hogy Digital Ocean-nél egy CentOS 6-os VPS-en nem lehet kernelt frissíteni, mert hivatalosan nem támogatott?

Aki használ DO-t, az mit tesz ez ügyben? Nem zavarja hogy kernel exploitok keringenek?

https://www.digitalocean.com/community/questions/do-you-update-kernels-…

Jelenleg teszt-, később archiválási célból szeretnék minden levélről egy másolatot küldeni egy másik szerverre.
Az always_bcc-t és módozatait ismerem, de logikailag nem tudok megbarátkozni vele, hogy
1., a levél maga a BCC bejegyzéssel módosul
2., 1 meghatározott címre továbbítja a levelet eredeti címzettől, feladótól függetlenül.

Tényleg nem képes a Postfix arra, hogy minden átmenő levelet _érintetlenül_ egy második transport-ra is kézbesítsen a levélre vonatkozó default transport mellett?
(természetesen tudva azt, hogy egy "fekete lyukba" dobálja a leveleket, tehát minden hiba, visszajelzés > /dev/null)

Eddig több órányi kereséssel összesen ezt találtam: http://pjrlost.blogspot.hu/2012/11/smtp-delivery-to-two-mail-servers-vi… , de ez egy kissé bizonytalannak tűnő házi írású script, amire nem szívesen bíznám a teljes céges levelezést.

Sziasztok!

Adott egy friss 13.2-es openSUSE, rajta a gyári repóból elérhető apache2 (2.4.10). Ezen a gépen szerettem volna egy új webalkalmazást kezdeni, azonban akadály(ok)ba futottam.
A yast2-httpd-server csomaggal kezdtem a konfigurációt, azonban a használt framework dokumentációjában szereplő config fájllal sem jutottam előre. A Yast2 a következő configot generálta:

<VirtualHost *>
DocumentRoot /home/richard/Projects/project_name/public
ServerName project_name.dev
ServerAdmin richard@localhost
<Directory /home/richard/Projects/project_name/public>
AllowOverride None
Require all granted
</Directory>
</VirtualHost>
(a framework által ajánlott configot itt találjátok)

Jelenleg az a helyzet a fenti configgal, hogy a projekt kezdőlapja megjelenik, viszont ha rewrite-ra kerülne a sor, akkor szépen dobálja a 404-es hibát. A mod_rewrite engedélyezve van természetesen.
Ha az AllowOverride-ot átírom "All"-ra, akkor 403-as error ("Access forbidden!") kapok - a kezdőlapon is.

Log-ban késő este semmi érdekeset nem láttam ezen kívül:
[Thu Mar 05 23:13:31.695186 2015] [authz_core:error] [pid 25695] [client 127.0.0.1:59161] AH01630: client denied by server configuration: /home/richard/Projects/project_name/public/
Ebből a bejegyzésből van egy raklappal a logban. Rákeresve a "client denied by server configuration" stringre mindenhol azt kapom megoldásként, hogy állítsam a Require opciót "all granted"-re, de mint fent látható, ez az alap kiindulási pont.

A framework által használt .htaccess-t megtaláljátok a configos linken (picit kell lejebb görgetni).
Apache, PHP, Framework config még gyári állapotban van.

Mi lehet a megoldás erre? Ha valami infóra még szükségetek van, akkor csak szóljatok.

Szerk:

Ezzel a config fájllal működik:
<VirtualHost *>
DocumentRoot /home/richard/Projects/project_name/public
ServerName project_name.dev
ServerAdmin richard@localhost
<Directory /home/richard/Projects/project_name/public>
AllowOverride All
Require all granted
Order allow,deny
Allow from all
Options All
</Directory>
</VirtualHost>

Bele kellene magam ásni ebbe az apache témába. :S

Hello,

A feladat egy kb. 60 fős csoportnak (R=0 userek) biztonságos, de egyszerű módon web-en elérhetővé tenni fájlokat.
Saját, host-olt megoldásban gondolkodnék a .htaccess-től elindulva, maximum egy nagyon egyszerű CMS megoldásig bezárólag.
WordPress-t és Joomla-t kerülném, ha lehet. Kliens program és hosszabb felhasználói okítás nélkül kellene működnie.
Az igazság az, hogy mialatt ezt leírtam már fele kód meglenne, ami ehhez kell, de hátha meg tudom úszni valahogy..

Sziasztok

Seafile Servert 2.x-ről 4.x-re frissítettem.
Elég az upgrade könyvtárban lévő
[...]
upgrade_3.0_3.1.sh
upgrade_3.1_4.0.sh
fájlokat egymás után lefuttatni?

2.x-es sea-cli is használok konzolos seafile kezelésre szerveren. Ez a verzió már nem kompatibilis a 4.x seafile szerverrel.
A 4.x sea-cli -vel viszont nem tudok köteteket szinkronizálni, mert ezt írja: The local directory is required.

/opt/seafile-client/seaf-cli sync -l "xxxxxxx-yyyy-bbbb-84f3-aebff594ae39" -s http://127.0.0.1:8000" -d /var/www/download/dir1" -u "a kukac b.hu" -p "xxxx"'

Próbáltam a sea-cli config fájlait törölni és az init procedúrát leffutatni, de ugyanaz. Hol lehet a gond?

Sziasztok!

Remélem nem kérdezek túl nyilvánvalót. :)

Van a cégünknél egy szoftver, ami felhőbe menti az adatokat, valamilyen API-n keresztül. A program belső fejlesztés, viszont egy másik országban levő anyavállalatnál készült. Ők nem ajánlanak ki nyilvános API-t, de nem is tiltják kifejezetten a felhasználást. (Nagyjából a "nem a mi gondunk, hagyjatok békén" reakciót adják a kérdésekre.)

Tudtok-e olyan (egyszerűbb) megoldásról, amivel bele lehet hallgatni a kommunikációba? Szeretnénk összekötni egy másik, Magyarországon készült és csak itt használt rendszerrel, hogy ne kelljen ugyanazokat az adatokat kétszer bevinni.

Nem kell feltétlenül kész megoldás (bár az lenne a legjobb :-)), elég ha tudtok mutatni valami anyagot, amivel már lehet kezdeni valamit.

Köszönöm!

Wikipedia igy foglalja ossze:

http://en.wikipedia.org/wiki/Representational_state_transfer#Example

Collection URI, such as: http://example.com/resources/

GET List the URIs and perhaps other details of the collection's members.
PUT Replace the entire collection with another collection.
POST Create a new entry in the collection. The new entry's URI is assigned automatically and is usually returned by the operation.
DELETE Delete the entire collection.

Element URI, such as http://example.com/resources/item17

GET Retrieve a representation of the addressed member of the collection, expressed in an appropriate Internet media type.
PUT Replace the addressed member of the collection, or if it doesn't exist, create it.
POST Not generally used. Treat the addressed member as a collection in its own right and create a new entry in it.
DELETE Delete the addressed member of the collection.

Figyeljuk meg a POST definiciojat: altalaban nem hasznaljuk, ill. amire hasznaljuk: egyedi elem eseten, ha az URI altal megadott egyedi elem onmaga is egy kollekcio, akkor ahhoz ad hozza egy uj elemet.

Tehat egyedi elem eseten a PUT szempontjabol nincs kulonbseg letezo vagy nem letezo elofordulas kozt, lecsereli azt. (Az egyedi elem a PUT altal megadott uj erteket vogja felvenni, lenyegtelen, hogy letezett-e mar korabban vagy nem.)

A POST viszont _mindig_ egy kollekciohoz ad uj erteket. Ezert ha egyedi elemet cimez az URI, akkor a POST nem az elemet csereli, ami most tehat maga is egy kollekcio, hanem az elemet, ami tehat egy kollekcio, boviti egy uj elemmel.

Visszaterve a PUT-ra: mindig cserel (a nem letezot is csereli), soha nem kreal, mig a POST mindig uj erteket ad a meglevok melle, tehat soha nem cserel.

CRUD-ra leforditva:
Create POST
Read GET
Update PUT
Delete DELETE

Ki hogy hasznalja, arra vagyunk kivancsiak.

Elore is koszonet a valaszokert!