http://blog.quitecloudy.com/2012/05/common-office-365-powershell-scripts.html

http://jrwpcs.com/checkdns.zip

Simple GUI-based tool for checking DNS records used in Office 365

Rather than having to run several NSLookup commands to verify Office 365 DNS records, simply plug your domain into DNS Checker and it will display all relevant Office 365 DNS records for your domain.
Download it here: http://jrwpcs.com/checkdns.zip

Csomagok használata, készítése

A DSM 3.2 óta a csomagokat nem kötelező saját gépről installálni (azaz előtte letölteni), hanem azokat már direktben http címmel is meghivatkozhatjuk. Két csomagforrást érdemes mindenféleképpen felvenni:

E pontokon számos érdekes csomaggal lehetünk gazdagabbak, és ami nem elhanyagolandó ezek mint App Hub-ok működnek, azaz folyamatosan frissülő tartalmúak.

Ezek mellett még a következő pontokon is érdemes a csomagok után szétnézni: http://www.mertymade.com/syno/
http://forum.synology.com/wiki/index.php/Synology_NAS_Server_3rd-Party_Application_Integration

További információk a csomagokról

• Hogyan telepítsük a csomagokat 
  Részletes leírás arról, hogyan telepítsük a gyáris és a 3rd Party csomagokat saját eszközünkre.
• FAQ Kérdések válaszok
• Alkalmazás csomagok felépítése Wiki oldal a csomagok felépítéséről, készítéséről 
• 3rd Party Alkalmazás Integráció Hogyan készítsünk alkalmazásokat, és miképp integráljuk azokat a Diskmanager szoftverbe

Az itthoni Synora nekiálltam összerakni, hogy lokális DNS szolgáltatást biztosítson (számtalan okom volt erre, ebben most nem mennék bele). Hozzáértők tudják, hogy ehhez a BIND szolgáltatást kell felvarázsolni az eszközre (lévén azért ez mégis csak egy Linux csoda), s ehhez az IPKG-ra van szükségem. A Syno számtalan változatban állítja elő a hardvereit, ás természetesen ezek eltérő processzor típusokon nyugszanak. Annak érdekében, hogy telepíteni tudjunk meg kell találnunk a számunkra szükséges verziót. Nos hiába túrtam az angol nyelvű dolgok között nem találtam semminemű leírást arra nézve pontosan melyik IPKG csomagra lesz szükségem melyik hardverhez.

Ezután belefutottam és elkezdtem átnézni – bár nem értek németül – egy dutch alapú wiki cikket. Ebben végre megleltem a számomra lényeges és naprakész (!) információt:

Die Installation von IPKG muss auf den vorhandenen Prozessortyp abgestimmt sein. Welchen Prozessortyp besitzt mein System?

cat /proc/cpuinfo | grep cpu

• Für ARM (armv5tejl): http://ipkg.nslu2-linux.org/feeds/optware/syno-x07/cross/unstable/syno-x07-bootstrap_1.2-7_arm.xsh
• Für PowerPC (ppc_6xx): http://ipkg.nslu2-linux.org/feeds/optware/ds101g/cross/unstable/ds101-bootstrap_1.0-4_powerpc.xsh
• Für PowerPC (ppc_85xx): http://ipkg.nslu2-linux.org/feeds/optware/syno-e500/cross/unstable/syno-e500-bootstrap_1.2-7_powerpc.xsh
• Für Marvell Kirkwood 88F6281, 88F6282, 88FR131 (ARMv5TE Feroceon) : http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/stable/syno-mvkw-bootstrap_1.2-7_arm.xsh
• Für Intel Atom: http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/syno-i686-bootstrap_1.2-7_i686.xsh

Neue, jedoch noch ungetestete Adressen gibt es hier: http://www.synology-forum.de/showthread.html?p=106324

Nem tudom az angol nyelvű cikkből ezt miért hagyták ki (ill miért csak az ARM procikon lovagoltam, amik ráadásul a kisebb verziókban vannak), de itten már minden lényeges dolog megvolt. Innentől a telepítés már nem nagy kunszt, akár a már idézett német cikk, akár a vonatkozó angol wiki bejegyzés alapján megoldhatjuk. Nagy előnye a cikknek, hogy már a DSM 4.0-ra is fel van frissítve!

Ezt követően az IPKG már szépen muzsikál a kis dobozban.

Az OneShar.es szolgáltatás mindkét fenti félelemre válaszol. A maximum 1000 karaktert tartalmazó titkos üzenet elküldésekor már a szolgáltató szerverére is titkosítva érkezik a tartalom, amelyet csak a címzett tekinthet meg egy webes URL ismeretében. A fogadónál megnyíló üzenet ráadásul csak egyszer tekinthető meg, az URL újrafelhasználásakor vagy egy egyszerű oldalfrissítésnél is már csak hibaüzenetet kapunk.
A rendszer használata egyszerű: elsőként írjuk be az üzenetet az ablakba, majd nyomjuk meg a Create Link gombot az egyszer használatos URL generálásához.

A következő ablakban megkapjuk a címzettnek szánt megtekintési hivatkozást, amelyet az egérrel kijelölve, vagy a hivatkozás alatti linkre kattintva a vágólapra küldhetünk.

Azoknak, akik ismerik munkáltatójuk informatikai szabályzatát, 70 százaléka vallotta be, hogy azt több-kevesebb rendszerességgel már megszegték. Az erre adott számos indok közül a leggyakoribb az volt, hogy szerintük semmi rosszat nem tettek ezzel (33 százalékuk vélte így). Minden ötödik válaszadó arról számolt be, hogy munkája elvégzéséhez nem engedélyezett programokat és alkalmazásokat használ, míg 19 százalékuk azzal mentegetőzött, hogy a szabályzat betartását nem ellenőrzik a munkahelyen. A válaszadók 18 százaléka szerint nincs idejük munka közben az informatikai házirenddel foglalkozni, míg mások arra hivatkoztak, hogy a szabályok betartása kényelmetlen (16 százalék), elfelejtkeznek róluk (15 százalék) vagy éppen a főnökük nem ellenőrzi őket (14 százalék).

Bár minden nap azért kűzdünk, hogy ne legyen probléma mégis ez a helyzet… Ezek fényében miért is lepődnek meg a felhasználók a problémákon, az elveszett adatokon, vagy az egyéb gondokon?

Idézet: bitport.hu

Hibajelenség

Az MVC alkalmazásom HTML form ablakában a mezők kitöltését követően a Submit folyamat megkezdésekor a rendszer az alábbi hibaüzenetet adta:

[InvalidOperationException: Operation is not valid due to the current state of the object.]
   System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded() +2420558
   System.Web.HttpValueCollection.FillFromEncodedBytes(Byte[] bytes, Encoding encoding) +58
   System.Web.HttpRequest.FillInFormCollection() +159

Hiba oka

A Microsoft 2011-12-29-én kiadta a Microsoft Security Bulletin MS11-100 – Critical szintű bejegyzést. A bejegyzés hibajavítására kiadták 2012-01-12-vel az MS KB Article ID 2661403 cikket és a hozzá kapcsolódó hibajavítást. Ez MINDEN eddigi Windows rendszerben a sérülékenységet orvosolja, viszont számomra ez a korlát jelenti a valódi problémát:

A rendszerekben ugyanis a DOS (Denial of Service) támadások elkerülése végett beépítésre került egy alapértelmezett válaszban megadható elemszám méret. Ez alapértelmezésben 1000! Amennyiben az ASP.NET form működése során ennél nagyobb elemszámmal találkozik, akkor a fenti hibaüzenettel fémjelzett kivételt dob.

Megoldás

Talán elsőre is látható, hogy a legegyszerűbb javítás az lenne, ha az elemszámot a számunkra szükséges mértékben megnövelnénk. Nos erre van lehetőség, az alkalmazás Web.Config fájl-t kell megfelelően kiegészíteni:

  <appSettings>

    <add key="aspnet:MaxHttpCollectionKeys" value="1500" />

  </appSettings>

Ezt követően az alkalmazás minden hibajelzés nélkül rendben lefut. Figyeljünk azonban a kapcsolóra és feleslegesen ne növeljük az elfogadható elemszámot, ezzel is védve az alkalmazást és futtató környezetét.

További információ:

• Microsoft KB Article
• December 2011 Out-Of-Band Security Bulletin Webcast Q&A
• Stackoverflow Post

Amikor azonban ha a legelejéről építünk fel valamit egy két apróság azért fejtörést okozhat. Nem nehéz egy új MVC projektet nyitni és nem nehéz az alapokat létrehozni. Amikor viszont szeretnénk egy új Controllert létrehozni, úgy hogy az már Entity Framework-t is használjon nagy piros X-be futunk bele. Vakargattam a fejem, mert nem emlékeztem elsőre miképp is léptünk annó a nagy keret építésekor túl ezen, de most megvan a válasz. Az MS oldalain egy elég jól sikerült, szájbarágós videós blogbejegyzés segít ennek a problémának a feloldásában:

http://msdn.microsoft.com/en-us/data/gg702905

Érdemes végignézni.

http://magazine.joomla.org/issues/Issue-Jan-2012/item/654-What-s-new-in-Joomla-2-5

Ez egy fejlesztőknek, tesztelőknek készült változat, aminek célja, hogy

• Lehetőséget teremtsen az egyedi és szabványos fejlesztések, kiadások előzetes tesztelésére
• Tesztelési lehetőséget nyújtson az 1.7 – 2.5 átmenet (upgrade) folyamatához
• Felhívja a figyelmet arra, hogy lassan itt az új év, és ismét letelik 6 hónap és jön a következő verzió

Fontos! Ez a változat nem alkalmas éles weboldalak létrehozásához, csak tesztelési célzattal kerül kiadásra!
 

Mik a várható mérföldkövek 2012-re?

• 2012 Február 10 – Joomla 1.7 lejár, tovább nem kerül támogatásra, frissítésre
• 2012 Április – Joomla 1.5 lejár, tovább nem kerül támogatásra, frissítésre
• 2012 Július – Megjelenik a következő – hosszú távú – Joomla! verzió

Fontos! A meghirdetett dátumok változhatnak a projekt terhelhetőségének függvényében.
 

Miképp lehet a 2.5-höz hozzáférni, frissíteni?

Az aktuálisan érvényes 2.5 B1-s verzió letöltéséhez kattints ide.

Amennyiben 1.7-es verziót használ, akkor a frissítés nem nehéz, csak használja az Extension Manager Install opcióját.

Amennyiben ön 1.5-s verziót használ, akkor a jUpgrade komponens telepítésére és használatára van szükség.
 

Milyen újdonságokat tartalmaz a 2.5 Beta 1?

Számos újdonság kerül kiadásra a jelen változatban. Ezek a következőek (kényelmi és értelmi okokból nem fordítottam ezeket le, akinek kell érti, a többieknek meg véleményem szerint mindegy a kiadásig):

• Menu item parameter "Note" (Marcell van Geest, Andrea Tarr)
• No "new user notification" email sent to admin (Kenny Wickstrom)
• Implementing default text per language in syndicate module (Jean-Marie Simonet)
• Implementing image option for the offline.php default page (Jean-Marie Simonet)
• Joomla! update notification button in the quickicons module (Nicholas Dionysopoulos)
• Debug Plugin Reloaded (Nikolai Plath)
• *Option to set Joomla to Site Offline (YES) during installation (fade2grey)
• Patch to enable change of newsfeed display direction (Mathieu Cattin)
• Add a true autoloader to the CMS (Rouven Weßling)
• Database Version Check (Mark Dexter)
• * "Select a Menu Item Type" in modal box in menu item edit page (Dennis Hermatski)
• *Improving SEO: New system plugin: languagecode (Jean-Marie Simonet)
• *Manager for Language Overrides (Patrick Alt)
• Easier workflow by linking Menu Manager: Add Menu to Module Manager: Module Menu (Andrew Eddie, Jacques Rentzke)
• Add an option to filter the mod_whosonline by groups of the connected user (Christophe Demko)
• Add a check for native ZIP support to the Installation (Rouven Weßling)
• Add ability to support other databases starting with Microsoft SQL Server (Hooduku Team)
• mod_status optimization (Kyle Ledbetter)
• Category filtering on content doesn’t including sub-categories (Ofer Cohen)
• User Notes (Andrew Eddie)
• Use the images and urls fields to create simple standardized layouts (Elin Waring)
• Custom Black List in Text Filters – Ready to test – Makes it possible to overwrite default blacklist – Joomla 1.7 (Tore B. Krudtaa, Denise McLaurin)
• Captcha in the core (Jonnathan S. Lima, Rouven Weßling)
• Finder Integration (Rob Schley, Michael Babker, Elin Waring, Chris Davenport, Omar Ramos, Viet Hoang Vu, Jean Marie Simonet, Rouven Weßling, Louis Landry, Gabriele Pongelli)

http://www.themepartner.com/blog/56/get-joomla-17-plugin-module-component-and-template-parameters/

#
# this is not correct for me
#
$ date
Wed Oct  1 07:43:58 CDT 2008
#
# to fix it
#
$ sudo rm /etc/localtime
$ sudo ln -s /usr/share/zoneinfo/Europe/London /etc/localtime
#
# now check it's ok
#

$ date
Wed Oct  1 12:42:33 GMT 2008

További infók: http://whomwah.com/2008/10/01/setting-the-timezone-on-centos/

Hi guys,

As with all things programming, there is no "right" or "wrong". I can tell you, however, what is the Model 2 paradigm followed by Joomla!’s MVC implementation. Joomla! is following the paradigm of "thin controller-fat model". The exact opposite is perfectly possible; neither one is The Absolute Truth, but since we’re developing for Joomla! we can at least follow Joomla!’s paradigm.

So, what are the three components of the MVC (Model-View-Controller) architecture supposed to do?

The Controller is the manager in the office. Its business is to instanciate the Model and set the model state based on the input parameters. In the current incarnation of Joomla!’s MVC implementation, this essentially means that the Controller will instanciate the Model and populate its state based on the request parameters. Since Joomla! is using a single view, multiple model approach, you may have more than one model objects instanciated by the controller. Then, the Controller instanciates the View, passes the model object(s) to it and asks the view to render itself.

The Model is the worker. It does all the heavy lifting. Based on its state (which was set by the Controller), the model performs some task. IMPORTANT! The common stupid mistake -which I have done many times in the past- is to decide what to do in the model based on request parameters. DON’T DO THAT! It’s wrong. The model should rely on its state and nothing but its state. If it needs to pass back information, it can either return them as return values of its methods, or modify its own state. Also, never EVER have the model render the data in a specific format. The model only deals with raw data. Making them pretty is the View’s responsibility.

The View is the user service department. Its only preoccupation is how to get the raw data from the model and render them into something useful, be it an HTML document, a JSON snippet or a CSV file. The View should get all of the data it needs from the model. A typical mistake -which I do a lot- is having the View fetch data directly from the request. Nope. Don’t do that, it’s wrong. The View only renders data, it doesn’t take decisions based on request data.

I should note that when talking MVC, we are usually referring to "triads". A triad of a controller, model and view can be seen as a standalone thing. It’s something which knows what to do (controller), how to do it (model) and how to present it (view). Take one of the components out and you have something unusable. However, if you want to make yourself a huge favour, the three components of an MVC triad should be completely decoupled, meaning that one should not be aware of how the other two work. The controller should have no "insider" knowledge about how the model and the view work; it just shifts data around. The model shouldn’t know how the controller or view work; it just acts on its state. The view should not know how the controller and model work; it just kindly requests data from the model based on the model state and displays it in an appropriate representation. Having the three components of the triad completely decoupled allows you to perform changes easily. You must be able to, for instance, modify how a model works -while maintaining the same public API- and neither the controller nor the view should require any changes at all. Or, you could add one more view -e.g. a JSON view of your data- without requiring any changes to your controller and/or model. You get the idea. Make stuff reusable and decoupled. Just like a roller bearing always works the same and doesn’t care if it’s used in a bicycle, motorbike or boat, your classes shouldn’t give a dime where they are used in and should perform always the same.

Further to the three foundation components of the MVC architecture, Joomla! also has two more strange beasts, called Tables and Helpers.

The Table is a strange animal in the Joomla! world. Conceptually, it’s a cross-breeed between a controller, a model and a data layer. In theory, a Table should be nothing more than a stupid adapter, a simple contraption to allow the model to request data from the database in an agnostic manner. The Joomla! implementation of a Table goes beyond that, and provides data manipulation methods (like hit() or publish()) which really belong to the model. Hence we have the strange case where the model calls a method in the table to do something as simple as publish or reorder records instead of the model itself modifying the relevant records.

The Helpers are the MVC purist’s worst nightmare. For us common mortals, however, the Helpers are our way to provide quick and dirty solutions which will come back to haunt us later on. The Helpers are supposed to be static classes, i.e. classes with nothing but static methods. They are commonly used to store reusable code which is required across a number of views, e.g. a combo box rendering the list of categories in a content management components. A very common mistake is to use the helper to hold some code which should better be put in a component, model, or view. Don’t do that. It’s code smell. Keep your Helpers lean and mean, with nothing but standalone static methods.

One thing missing from Joomla! –actually not missing, just never spelled out– is the Dispatcher.

The Dispatcher is responsible for doing pre-flight events, like loading language files and doing sanity checks, selecting a controller and running it – and, finally, processing any redirection requested by the controller. Joomla! gets away with having a split personality disorder when it comes to dispatchers. Half of the dispatcher’s code is implemented in the core, called when the application is routing itself. The other half of the dispatcher’s code exists outside of any class, in the entry point files of your components. For example, the dispatcher of the back-end part of com_example would be administrators/components/com_example/example.php (in Joomla! 1.0 it would be admin.example.php, making the naming convention even more funky).

With this knowledge in mind I think that you should never have to ask anybody else a question like "where am I supposed to put the code that does X". Think what your code does and you’ll see where it belongs.

Have I followed this approach with all of my components? Hell, no! Tons of my code dates back before I had enough theoretical background to consider proper architecture. Some of my components have gotten better over time and now that I’m rewriting Akeeba Subscriptions using the Joomla! framework I try to abide by these rules as much as practically possible. And here is my Uncertainty Clause: sometimes, following those rules may require you to write a bit more complex code than you would, which needs a little more time than you have. In those cases of uncertainty and doubt, you will end up doing a quick hack and get done with it. That’s perfectly possible. But beware! Those quick hacks will come back to haunt you. After you do such a hack and release your code, do take some time to refactor it to better architecture. The benefits will start being apparent when, after six months or so, you try to modify that code. Trust me on that, that’s the time when quick hacks come back to haunt you and they do it with extreme prejudice.

Keep on coding,

…

Well, yeah, but helpers should really be called "template helpers" and used only for this kind of reusable GUI code. If you have cross-component reusable code which doesn’t fit into an MVC component or a Table class, you’re probably talking about something which could be spun off as a Library instead.

The Tables, as I said, are a strange beast. They are not data layer adapters (which they should be), they are not controllers (even though they include some bits of controller code) and they are not models (even though they act like they are). IMHO, that’s the rough spot in Joomla!’s architecture. ORM is a nice workaround, but not not necessarily the ideal one for all cases I would rather have something like Nooku’s Table/RowSet/Row collection for database accessor classes. After all, a Table belongs to the data layer, unlike what Joomla! does.

Regarding your rating, I would give 3/5 for MVC implementation, due to two issues:
- The Table thing, which violates the otherwise beautiful MVC implementation
- The, in my opinion, erroneous execution of MVC in the default JController code. Instead of hinting the developer that you should actually change the state of a single model object instance to be attached to a single view object instance, the way getModel and getView are coded make you believe the opposite. This kept me confused for years, as I don’t have any CS background. It took a Nooku presentation by Johan Janssens to finally understand how MVC is supposed to work.

…

If you take a look at JController::display() you will see that it’s doing something right. It creates a model and a view model, assigns the model to the view and asks the view to render itself. However, the getView() and getModel() methods do not return a Singleton instance of those objects. Every time you call them, they return a new object. This means that you can’t do something like:

$model = $this->getModel();
// Do something with the model
$this->display()

to create a new controller task. You are left wondering what you should do, with a cryptic comment in the docblock of display() stating that developers should override this method with their implementation. What it really means, is that all tasks should actually copy this code, but this is an overkill. Who wants to copy the same code over and over again for each task, on each controller of every MVC triad he creates? It also leads to a gross misunderstanding, that the model and view objects are "disposable" and that the controller is responsible for getting the data off the model and push it into the view. This is wrong. It couples the three objects. The controller should only tell the view "here is your model, go render yourself; you guys talk to each other". If you take a look at the code of the most popular component on JED, you’ll see this misunderstanding going on a lot (I was guilty of doing that, too, up until a few versions ago in my software).

If you want to see an example of how things could be to make things easier for a developer, just take a look at the default.php controller in Admin Tools Core or Akeeba Release System. Take a look at getThisModel(), getThisView() and display(). Still, it’s not a perfect solution (the multi-model, single view case is a bit of a kludge), but it’s better than the default JController implementation. To the core developers’ credit, this was partially fixed in the Joomla! Platform with the introduction of the specialised controller class, i.e. JControllerAdmin. Even that is still not a perfect solution, as the task methods are still huge black boxes, but at least Joomla!’s MVC implementation is becoming more intuitive to new developers.

More : According to MVC archetecture should Add, Edit and Remove Record functions be in the model or the controller?

A szükséges DB létrehozás után minden ment is szépen, de nem tudtam komponenseket felvenni, mert létrehozási hibával elhajtott a rendszer…

JFolder::create: Could not create directory

Warning! Failed to move file.

Első lépésben az 1.5 és 1.6 alól ismert megoldással próbálkoztam, de nem ez volt a gond. Másodikra nézegettem milyen könyvtárakat akar használni és ekkor jutottam nagy (?) felfedezésre – bár gondolhattam volna rá – mégsem módosítottam a rendszer által használt TMP és LOG könyvtárak útvonalát.

Elsőre megadtam a valós útvonalat, de ez sajnos nem segített. Sebaj gondoltam és és megadtam relatív címzéssel, s lássatok csodát, elindult! Mindezek alapján a megoldás, hogy a Webhely / Globális konfigurációban módosítani kell a

• Rendszer / Naplózási mappa elérési útját – ./log
• Kiszolgáló / Ideiglenes mappa elérési útja – ./tmp

Ha valaki jobban szeret editorokkal dolgozni, akkor a configuration.php-ban a bejegyzéseket a következők szerint kell módosítani:

• $log_path = ‘./log’;
• $tmp_path = ‘./tmp’;

Ezt követően a dolog végre úgy működik ahogy kell és minden mehet a megszokások szerint!